Understand RESTful Concepts

RESTful

Baidu Encyclopedia says: RESTful is a software architecture style, design style, rather than a standard, only provides a set of design principles and constraints. It is mainly used for client and server interaction class software. Software designed in this style can be simpler, more hierarchical, and easier to implement mechanisms such as caching.

According to Wikipedia, REpresentational State Transfer (REST) is an architectural style that defines a set of HTTP-based constraints and attributes. Web services that conform to the REST architectural style, or RESTful, provide interoperability between computer systems on the Internet. Rest-compliant Web services allow the resources of a Web system to be accessed and manipulated using uniform and predefined stateless requests. 【 translation is not accurate please include 】

It is important to note that representational state transfer is a design style rather than a standard. REST is usually based on existing widely popular protocols and standards using HTTP, URI, and XML and HTML.

• Resources are specified by URIs.
• Operations on resources include obtaining, creating, modifying, and deleting resources, which correspond to the GET, POST, PUT, and DELETE methods provided by the HTTP protocol.
• Manipulate a resource by manipulating its representation.
• Resources are represented as XML or HTML, depending on whether the reader is a machine or a human, a client software consuming a Web service or a Web browser. It can also be any other format.

Directive constraints define a RESTful system. These constraints restrict how the server can process and respond to customer requests so that by operating within these constraints, the service gains desired non-functional attributes such as performance, scalability, simplicity, modifiability, visibility, portability, and reliability. A service cannot be considered RESTful if it violates any of the required constraints.

Client-server The principle behind the client-server constraint is separation of concerns. Separating user interface issues from data storage issues improves user interface portability across multiple platforms. It also improves scalability by simplifying server components. Perhaps most important for networks, however, is the separation that allows components to evolve independently, thus supporting the Internet-scale requirements of multiple organizational domains.

Stateless [stateless protocol] Client-server communication is limited by the fact that no client context is stored on the server between requests. Each request from any client contains all the information needed to service the request, and the session state is stored in the client. Session state can be transferred from the server to another service, such as a database, to maintain a persistent state for a period of time and allow authentication. The client starts sending requests when it is ready to transition to the new state. The client is still in transition, even though one or more requests are incomplete. The representation of each application state contains links that may be used the next time a client chooses to initiate a new state transition.

Cacheability [Web caching] In the case of the World Wide Web, clients and intermediaries can cache responses. Therefore, a response must implicitly or explicitly define itself as cacheable or not prevent clients from reusing outdated or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client-server interactions, further improving scalability and performance.

Layered systems [Layered systems] The client is often unable to tell whether it is directly connected to the end server or to a middleman. Mediation servers can improve system scalability by enabling load balancing and providing shared caches. They may also enforce security policies.

Unified Interfaces Unified interface constraints are fundamental to any REST service design. It simplifies and separates the architecture so that each part evolves independently. The four constraints of this unified interface are:

• Resource identification in a request Identifies individual resources in a request, such as using URIs in a Web-based REST system. The resource itself is conceptually separate from the representation returned to the client. For example, a server can send data from its database as HTML, XML, or JSON, none of which is an internal representation of the server.

• Resource processing by presentation When a client holds a representation of a resource, including any additional metadata, it has enough information to modify or delete the resource.

• Self-descriptive messages Each message contains enough information to describe how the message is processed. For example, which parser to invoke can be specified by Internet media type (formerly known as MIME type).

• Hypermedia as an engine for application state (HATEOAS) After accessing the initial URI of a REST application (similar to a human Web user visiting the home page of a Web site), REST clients should be able to dynamically use the links provided by the server to discover all available actions and resources needed. As the access progresses, the server responds with text containing hyperlinks to other actions that are currently available. The client does not need to hardcode information about the structure or dynamics of the REST service.

RESTful API

When I first started PHP, I didn’t know so many ways. I felt that I had succeeded in accessing this file. When the URL is: https://example.com/balabala.php?resources=233&fdsafdafdfa=… Later, contact the first frame Laravel, suddenly see this URL: https://example.com/resources/233/fdsafdafdfa/… Immediately feel in front of a bright, comfortable. But I don’t know what the difference is between the two, with the step by step in-depth use and study of the framework. The nginx/ Apache configuration is a problem. If you do not use the framework, you will use the Web server to access the PHP file URL:

The test / -- -- -- -- -- project folder ├ ─ ─ Cl. PHP -- -- -- -- -- url:http://www.test.com/Cl.php?param=... ├ ─ ─ index. PHP └ ─ ─ te    └── iiii.php             ----- url: http://www.test.com/te/iiii.php?param=...
Copy the code

With frameworks, the nginx configuration points to the index.php entry file in the public folder. URL parsing is no longer the responsibility of the Web server. But changed to use PHP to be responsible for oneself, according to the corresponding URL such as http://www.test.com/id/1 MVC or other design patterns for resource parsing and loading the specific way here, please refer to the document itself).

Web service apis that follow REST architectural constraints are called RESTful apis. An HTTP-based RESTful API defines the following aspects:

• basicURL, e.g.http://api.example.com/resources
• Define the state transition of data elements Internet media type (for example, the Atom, microformats, application/VND. Collection + json). The current representation tells the customer how to write transitions to all the next available application states, which can be as simple as a URL or as complex as a Java applet.
• Standard HTTP methods (for example, OPTIONS, GET, PUT, POST, and DELETE)

Here are some sample urls

So * GET /tickets - Retrieves a list of tickets * GET /tickets/12 - Retrieves a specific ticket * POST /tickets - Creates a new ticket * PUT /tickets/12 - Updates ticket #12 * PATCH /tickets/12 - Partially updates ticket #12 * DELETE /tickets/ 12-ticket #12 Deletes or * GET /tickets/12/messages - Retrieves list of messages for ticket #12 * GET /tickets/12/messages/5 - Retrieves message #5 for ticket #12 * POST /tickets/12/messages - Creates a new message in ticket #12 * PUT /tickets/12/messages/5 - Updates message #5 for ticket #12 * PATCH /tickets/12/messages/5 - Partially updates message #5 for ticket #12 * DELETE /tickets/12/messages/5 - Deletes message #5 for ticket #12Copy the code

Representational State Transfer (REST)

: when the 2018-04-23