A brief introduction to rest architecture style

Http://www.cnblogs.com/loveis715/p/4669091.html

When it comes to rest, I think everyone's first reaction is "Ah, that's the way to communicate back and forth." "But few people can articulate exactly what it is and what guidelines to follow when it comes to asking for details about the constraints it presents and how it starts to build rest services."

In this article that you will see, we will provide a detailed introduction to rest, especially the rest services based on HTTP. With these articles, you can learn not only what rest is, but also what the rules you need to follow when writing a rest service, the various factors to consider when designing the RESTful API, and the issues that you might encounter during the implementation process.

Rest Example

I think a lot of readers may not know exactly what the rest of the concept is. So first let's look at a simple example of a rest service based on HTTP.

Suppose the user is visiting an ecommerce web site www.egoods.com. The site has a detailed breakdown of the items it sells. When a user logs on to the site for shopping, he first needs to select the category on the site where he needs to look for items, and then list the items that belong to that category.

Of course, although this process is very simple from the business logic standpoint, in fact the browser sends multiple requests to the background: page logic will first get all categories of merchandise in the page load, and these categories will be displayed on the page. When the user selects a category, the page logic sends a request to get the details of the category and sends another request to get a list of the items for that category:

When viewing these requests through the debugging capabilities of the browser, we can see that they first send a GET request to www.egoods.com/api/categories for all categories of merchandise:

1 get/api/categories
2 Host:www.egoods.com
3 authorization:basic xxxxxxxxxxxxxxxxxxx
4 Accept: Application/json

And the server will return all categories:

1 http/1.1 OK
 2 content-type:application/json
 3 content-length:xxx
 4  
 5 [
 6    {
 7       "Label": "Food",
 8       "url": "/API/CATEGORIES/1"
 9    }, {       "label": "Clothing", one       " URL ":"/api/categories/2 "
...    {"       label": "Electronic Equipment", "       url": "/api/categories/25"
18]

The response returns an array represented by JSON. Each element in the array contains two pieces of information: the label that the user can read to represent the category name and the URL corresponding to the corresponding classification. The category name that the label records is displayed to the user in the page. When a user chooses a category based on the category name labeled by the label, the page logic takes the URL of the category and sends a request to the URL to get the details of the classification. For example, when the user clicks on the "Food" category, the browser will send the following request to the server:

1 get/api/categories/1
2 Host:www.egoods.com
3 authorization:basic xxxxxxxxxxxxxxxxxxx
4 Accept: Application/json

This time, the page logic gets its corresponding URL based on the user's choice of "food" for the category, and sends a GET request to the URL. And the response to the request is:

http/1.1 OK
Content-type:application/json
content-length:xxx
 
{
   "url": "/api/categories/1", "
   label": "Food",
   "Items_url": "/api/items?category=1",
   "Brands": [
         {
            "label": "Friend",
            "" Brand_key ":" 32073 ","
            url ":"/api/brands/32073 "
         }, {
            " label ":" Pleasure ",
            " Brand_key ":" 56632 ",
            "url": "/api/brands/56632"
         }
         ...
   ],
   "hot_searches": ...
}

The response is slightly more complex. First, the URL in the response identifies the URL for the food category. The Label property, as before, is used to display the name of the category on the page. A more specific attribute is the Items_url. It is used to indicate the URL for each product that belongs to the food category. The attribute brands is used to list famous brands in the "food" category, such as Friends of the courtiers, pleasures and so on. These brands are organized into an array of objects, and each object in the array has attributes such as Label,url. With the help of these properties, the page can list the names of these famous brands and allow the user to click to jump to the corresponding pages of these brands. In addition to these attributes, the food taxonomy includes a range of other attributes, such as the hot_searches properties that are currently being searched by other users, and so on.

One problem with this response is that each product that matches the user's filtering criteria is not included in the response. This is because the products listed on the page vary according to the filter criteria that the user sets, that is, the brand they choose, and the search keywords. Therefore, the page logic will be the target URL based on the attribute Items_url and the search criteria set by the user, sending the request to the background again to request the items that need to be displayed on the page.

For example, when a user wants to browse only the food belonging to the pleasure brand, it can hook the brand of pleasure, then the URL will consist of the items_url of the food classification and the URL parameters that indicate the filter according to the brand:

1 get/api/items?category=1&brand_key=56632
2 Host:www.egoods.com
3 authorization:basic Xxxxxxxxxxxxxxxxxxx
4 Accept:application/json

Now let's summarize the entire running process of the HTTP-based rest system shown above. At the beginning, we got a list of all the categories. The entries in the list not only contain information such as the category name that the user can see, but also have an additional URL attribute. When the user selects an item in the list, the page logic sends a request to the corresponding URL to obtain the details of the item. In this detail, some of the content also contains some other URLs, allowing the page logic to send the request through the URL property.

You might say, hey, it's not the same as the running process of our existing system. Yes. In the example cited above, we also give more emphasis to the Hateoas (hypermedia as the Engine of application state) characteristics that rest systems need. It is because this feature has been widely used in the systems that we have created, so I prefer to start with the familiar, rather than begin with a very dogmatic way of saying that rest must be so, must be that way, to increase the difficulty of learning.

Conversely, the rest services shown above are not typical. With a good understanding of rest, you will find that rest in the system design perspective will no longer place the process in the top priority.

In the later chapters, we'll start with a detailed description of how to create a pure HTTP based rest service.

Definition of rest

OK, now let's look at the definition of rest. Wikipedia describes it in this way:

Representational state Transfer (REST) is a software architecture style consisting to guidelines and best practices for CR Eating scalable Web services. REST is a coordinated set of constraints applied to the "design of" components in a distributed hypermedia system that can L EAD to a more performant and maintainable architecture.

From the definition above, we can see that rest is actually an architecture for organizing Web services, not a new technology for implementing Web services as we imagine, and no need to use HTTP. The goal is to create a distributed system with good scalability.

Conversely, as a schema, it presents a series of schema-level constraints. These constraints are: using the client/server model. Customers and servers communicate with each other through a unified interface. Hierarchy of the system. In a rest system, the client does not deal with a server in a fixed manner. No state. In a rest system, the server does not store any state for the customer. That is, the client itself is responsible for maintaining the state of the user and is required to provide sufficient information each time the request is sent. can be cached. The rest system needs to be able to cache requests appropriately to minimize the transfer of information between the server and the client to improve performance. A unified interface. A rest system needs to use a unified interface to complete the interactions between subsystems and between services and users. This allows each subsystem in the rest system to complete evolution on its own.

If a system satisfies the five constraints listed above, the system is called restful.

Let's egoods This example again through an ecommerce website to help us understand these constraints. First, Egoods is an E-commerce site. Users need to access the content of the site through browsers, mobile phones, or web browsing applications published by the website. So the client/server model is used naturally. In the browsing process, users need to access different types of data, such as product description, shopping cart and other information. This information may be provided by different servers in the Egoods Web service, so you may need to interact with more than one server during user browsing. If any state of the customer is saved on the server side, the client's state needs to be synchronized between the services when the user interacts with the different servers, greatly increasing the complexity of the system. As a result, rest requires the client to maintain its own state and to provide the information it has stored to process the request each time it is sent. It is also easy to understand the use of caching in a local way. When a client requests a message that has not changed since the last request, such as a product classification list, the server only needs to return a 304 response.

As you can see here, the other three constraints are common and easier to achieve in HTTP based Web services, except that the first four constraints are more specific than stateless. Stateless constraints are not very common in other types of Web services, so how to avoid violating them is the topic most often discussed when implementing rest services. Not only does it affect the design of many functions, it is also the key to the extensibility of rest systems. So in the later chapters, we'll explain the stateless constraints separately.