Rest full name is representational state Transfer, Chinese meaning is the representation of the status transfer. It first appeared in the 2000 Roy fielding doctoral dissertation, and Roy Fielding was one of the main authors of the HTTP specification. In his paper, he mentions: "The purpose of my writing is to understand and evaluate the architecture design of network-based application software in accordance with the principle of architecture, and to obtain a structure with strong function, good performance and suitable communication." Rest refers to a set of schema constraints and principles. "If an architecture conforms to rest's constraints and principles, we call it a restful architecture."
Rest itself does not create new technologies, components, or services, and the idea behind restful is to use the existing features and capabilities of the web to better use some of the guidelines and constraints in existing Web standards. While rest itself is deeply affected by web technology, the rest architecture style is theoretically not bound to HTTP, except that HTTP is currently the only instance of rest. So the rest we describe here is also the rest that is implemented via HTTP.
2 Understanding RESTfulTo understand the restful architecture, you need to understand what the phrase representational state transfer means, and what its meaning is in every word. In the following, we combine the rest principle and discuss the resources, and enumerate some key concepts and explain them from the view of resource definition, acquisition, expression, association, state change, etc.
The rest full name is the representational state transfer, what exactly does it mean? In fact, it refers to resources. anything, as long as there is a need to be quoted, it is a resource. A resource can be an entity (such as a mobile phone number), or it can be an abstract concept (such as value) . Here are some examples of resources:
For a resource to be recognized, a unique identifier is required, and the unique identifier in the web is the URI (Uniform Resource Identifier). A URI can be considered either the address of a resource or the name of a resource. If some information is not represented by a URI, then it is not considered a resource, it is only a bit of information about resources. the design of URIs should follow the principle of addressable, self-descriptive, and need to be intuitively correlated in form . Here is an example of a GitHub site that gives some pretty good URIs:
Let's look at some techniques for URI design:
Once on the Web The URI is cold numbers or meaningless strings, but now more and more sites use _ or-to separate some words, so that the URI looks more humane. For example, China's more well-known open source Chinese community, its news address on the use of this style, such as Http://www.oschina.net/news/38119/oschina-translate-reward-plan.
For example, the above/git/git/commit/e3af72cdafab5993d18fae056f87e1d675913d08 represents a multi-level resource, referring to a git user's Git project for a commit record, or for example/orders/2012/ 10 can be used to represent the order record for October 2012.
A lot of people just think of simple as the transfer of parameters, it is easy to cause the URI is too complex, difficult to understand. You can use it to filter resources, for example,/git/git/pulls is used to represent all push requests for a GIT project, and/pulls?state=closed is used to represent a push request that has been closed in a git project. This URL usually corresponds to a query result of some particular condition or the result of an algorithm operation.
Sometimes we need to represent the relationship of a sibling resource when it can be used, or, to be split. For example, one day GitHub can compare the difference between a file's random two commit records, or it might be possible to use/git/git/block-sha1/sha1.h/compare/ e3af72cdafab5993d18fae056f87e1d675913d08; BD63E61BDF38E872D5215C07B264DCC16E4FEBCA as a URI. However, GitHub is now using ... To do this thing, such as/git/git/compare/master...next.
2.2 Unified Resource InterfaceThe restful architecture should follow the unified interface principle, and the unified interface contains a limited set of predefined operations, regardless of the resources, that are accessed by using the same interface for resources . Interfaces should use standard HTTP methods such as Get,put and post, and follow the semantics of these methods.
if resources are exposed according to the semantics of the HTTP method, then the interface will have security and idempotent features , such as get and head requests are safe, no matter how many times the request does not change the server state. The, put, and delete requests are idempotent, regardless of how many times the resource is manipulated, and the result is always the same, and subsequent requests do not have more impact than the first time.
The following is a list of typical uses of Get,delete,put and post:
GETGet representation when changing (cache)
(OK)-Indicates that a response has been issued
Update the resource (optimistic lock) if it has not been modified
(OK)-If the existing resource has been changed
Update the resource (optimistic lock) if it has not been modified
(OK)-If an existing resource has been changed
Delete a resource
(OK)-The resource has been deleted
Let's look at some of the common problems in practice:
The difference between post and put in creating a resource is whether the name (URI) of the resource being created is determined by the client. For example, to add a Java classification to my blog, the generated path is the classification name/categories/java, then you can use the Put method. But many people directly correspond to the crud on post, GET, put, delete, for example, in a typical rails-implemented restful application. I think this is because rails defaults to using the ID generated by the server as a URI, and many people are practicing rest through rails, so it's easy to misunderstand.
This is true, especially for older browser-based clients that support only get and post two methods. In practice, both the client and the server may need to make some compromises. For example, the rails framework supports the delivery of real-world request methods by hiding parameter _method=delete, whereas a client-side MVC framework like backbone allows for the passing of _ Method transfer and set the X-http-method-override head to circumvent this problem.
The unified interface does not prevent you from extending the method, as long as the method has specific, recognizable semantics for the operation of the resource, and can maintain the unity of the entire interface. Like WebDAV, the HTTP method has been extended to add lock, Uplock, and other methods. The GitHub API supports the use of patch methods for issue updates, such as:
Patch/repos/:owner/:repo/issues/:number
However, it should be noted that, like patch, this is not the HTTP standard method, the server needs to consider whether the client can support the problem.
The Uniform Resource interface requires the use of standard HTTP methods to manipulate resources, so URIs should only represent the names of resources, not the operations of resources. In layman's terms, URIs should not be described using actions. For example, here are some URIs that do not conform to the uniform interface requirements:
Delete/deleteuser/1
If a GET request increases the counter, does this violate security?
Security does not mean that requests do not have side effects, such as many API development platforms, which restrict request traffic. Like GitHub, you limit requests that are not certified to request only 60 times per hour. But the client does not make these get or head requests for the sake of side effects, and the side effect is the service side is "on the Go". Also, the service side should not be designed to make the side effects too large because the client considers these requests to have no side effects.
Even if you use them in the original intent of each verb, you can still easily disable the caching mechanism. The simplest way to do this is to add a header to your HTTP response: Cache-control:no-cache. At the same time, however, you are also losing support for efficient caching and re-authentication (using the etag mechanism). For clients, when implementing a program client for a restful service, you should also take advantage of the existing caching mechanism to avoid retrieving the representation every time.
As shown, the HTTP response code can be used to cope with different situations, and the correct use of these status codes means that the client and server are able to communicate at a richer level of semantics. For example, the 201 ("Created") response code indicates that a new resource has been created with its URI in the location response header. If you don't take advantage of the rich application semantics of HTTP status codes, you'll miss the opportunity to improve reusability, enhance interoperability, and increase loose coupling. If these so-called restful applications have to be able to give an error message by responding to the entity, then soap is like this, and it can be fulfilled.
2.3 Presentation of resourcesAs mentioned above, the client can get resources through the HTTP method, right? No, to be exact, the client gets only the description of the resource. resources in the outside world, can have a variety of representations (or become representations, representations) form, between the client and the server is also the expression of resources, rather than the resources themselves . For example, text resources can be in HTML, XML, JSON and other formats, images can be displayed using PNG or JPG. resource representations include metadata for data and descriptive data , such as the HTTP header "Content-type", which is a metadata attribute.
So how does the client know what kind of representation is available on the server?
The answer is that through HTTP content negotiation, the client can request a specific format representation through the accept header, and the service side tells the client the presentation of the resource through Content-type.
In GitHub, for example, request a JSON-formatted representation of an organization's resources:
If GitHub is able to support the presentation format in XML format, then the result is this:
Let's look at some of the most common design practices:
Some APIs carry a version number in the URI, for example:
If we understand the version number as a different representation of the resource, we should just use a URL and distinguish it by the accept header, or GitHub, for example, the full format of its accept is
Application/vnd.github[.version].param[+json]
For the V3 version, it is accept:application/vnd.github.v3. For the above example, the same can be used with the following header:
Accept:vnd.example-com.foo+json; version=2.0
Use URI suffixes to differentiate presentation formats
Like the rails framework, it supports the use of/users.xml or/users.json to differentiate between different formats. Such a way is undoubtedly more intuitive for the client, but it confuses the name of the resource and the representation of the resource. I personally think that it is still preferable to use content negotiation to differentiate the presentation format.
What should I do when the server does not support the requested presentation format? If the server does not support it, it should return an HTTP 406 response, which indicates that the request was denied processing. The following is an example of GitHub, which shows the results of a request XML presentation resource:
2.4 Links to ResourcesWe know that rest is using standard HTTP methods to manipulate resources, but it is simply too simplistic to understand the Web database schema with curd. This anti-pattern ignores a core concept: " hypermedia is the application state engine (hypermedia as the engines of application states)". What is Hypermedia? When you browse a Web page, jumping from one connection to the next and jumping from another to another page takes advantage of the hyper-media concept: linking resources together.
To achieve this, it is required to include a link in the presentation format to guide the client. In the book "RESTFul Web Services", the author makes this link-like feature a connectivity. Let's take a look at some examples below.
Here's a request for GitHub to get a list of items under an organization, and you can see how the link header tells the client how to access the next and last page of records in the response. In the response body, the URL is used to link the project owner and the project address.
Another example is the following example, after creating an order through the link to guide the client how to pay.
The above example shows how hypermedia can be used to enhance the connectivity of resources. Many people use a lot of time to look for beautiful URIs while designing a restful architecture, ignoring hypermedia. Therefore, it should take more time to provide a link to the presentation of resources, rather than focusing on "resource crud".
2.5 Transfer of the stateWith the cushion above, it is easy to understand the state transitions in rest. But let's discuss the principle of stateless communication in the rest principle. At first glance, it seems paradoxical, since there is no state, how to state transfer one said?
In fact, the principle of stateless communication here is not that the client application cannot have a state, but that the server should not save the client state.
2.5.1 Application Status and resource statusin fact, states should differentiate between application state and resource state, the client is responsible for maintaining the application state, and the server maintains the resource state . The client-to-server interaction must be stateless, and every request contains all the information needed to process the request. The server does not need to keep the application state between requests, only the server will pay attention to the application state when the actual request is accepted. This stateless communication principle enables the service side and the intermediary to understand the individual requests and responses. In multiple requests, the same client no longer needs to rely on the same server for a highly scalable and highly available service side.
But sometimes we make designs that violate the principle of stateless communication, such as using cookies to track a server-side session state, a common jsessionid like the Java EE. This means that the cookie that the browser sends out with each request is used to build the session state. Of course, if a cookie holds information that some servers do not rely on for session state validation (such as authentication tokens), such cookies are also in accordance with the rest principle.
2.5.2 Transfer of application stateIt is well understood that the "session" state is not stored as a resource state on the server, but is tracked by the client as the application state. The client application status changes under the guidance of the hypermedia provided by the server . The service side tells the client through hypermedia which subsequent states of the current state can be entered. These kinds of links, like "Next page", are the function of this propulsion state – to show you how to move from the current state to the next possible state.
3 SummaryNow the Guangdong XXX version, XXX and other projects are using the traditional RPC, soap way of Web services, and mobile South base XXXX Project backstage, although the use of JSON format for interaction, but still belongs to RPC style. This paper attempts to quickly understand the concept behind the restful architecture from the perspective of definition, acquisition, representation, relevance and state change of resources. RESTful architecture and traditional RPC, soap and other ways in the concept of a great difference, I hope this article can be helpful for you to understand rest.
Understanding RESTful schemas
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
