Rest architectural Style Introduction II: CRUD

Reprinted from: Todd Wei http://www.cnblogs.com/weidagang2046/archive/2009/05/09/1453065.html

In the previous section, we first experienced the taste of the rest state expression transfer through two examples, but it should be pointed out that these two examples are simply resource acquisition. Rest is a resource-centric, no-service concept, and it really makes you wonder if rest can support complex applications like an orb or SOA? Before answering this question, let's leave rest for a moment and turn our eyes to a 3-tier architecture based on a relational database.

Typically, the business logic layer provides a number of functional interfaces (defined in IOrderService) externally, accessing the database internally through the data access layer. We know that the relational database only defines CRUD (Create, Read, Update, Delete) Four standard data operations, which correspond to the Insert/select/update/delete four SQL statements respectively. Experience has taught us that relational databases perform relational operations on several tables to support a variety of complex business logic, since all business functions will eventually be mapped to crud four standard operations on the database. The following interesting triangle can help us understand the problem:

The triangles in the graph represent: data type, operation, instance. Can think of them as adjustable buttons, the way the business logic layer is: Define a small number of service instances, put a lot of operations under the service instance, figuratively likened to "a door, there are a lot of things"; the database is provided with a large number of data instances and crud Four standard operations, can be likened to the " A lot of doors, every door with a small amount of stuff. "

Resource-centric rest and data-centric relational databases are similar. Data and resources are essentially state, the operation of the state crud one less, one more redundant. Therefore, rest also uses crud four standard operations, respectively, corresponding to the HTTP protocol Post/get/put/delete method. Although the HTTP protocol supports methods such as head outside of Post/get/put/delete, these nonstandard methods can be used as useful additions, but should not affect the purity of the rest model. In the previous section, we saw the rest-style application like a state machine, and here we see it like a database. The resources (URLs) that are defined by rest and the corresponding actions are as follows (it is worth repeating that the meaning of the URL is "Uniform Resource Locator" to see its versatility, which is also the advantage of Rest resource representation):

Rest is a perfect combination of the HTTP protocol, so it's easier to seamlessly connect to the Internet. In addition, it was mentioned that "the number of pages exposed to a Web site can be used as an indicator of how much it contributes to the Internet", and if from this perspective, a resource-centric rest approach is more friendly to the Internet than a service-centric SOA. But what style of architecture should be used depends on the characteristics of the application itself, generally, for the provision and management of data-based, and want to do SEO applications suitable for rest style, which includes most WEB2.0 applications, and based on computing and business logic, and the emphasis on security applications are not suitable for restful style. But avoid the preconceived use of service-oriented thinking, and sometimes the rest of the proper use of state-expressed transfer patterns can not only achieve business logic, but also have better scalability, as discussed in the previous section of the psychological testing services and Google search. The value of rest is to give us a perspective when designing the architecture, the so-called "vision determines the world".

Cache

Because rest URLs represent resources and stateless service features, the cache mechanism becomes unusually simple and has direct support in the HTTP protocol. The server response can specify the resource cache time through Cache-control:max-age,expires, and the last-modified parameter of the response header can indicate the last modification time of the resource, and the client request can take the if-modified-since parameter , if the resource is not expired, the server only needs to return 304 not modified state, which avoids the server-side duplication of work, but also save network bandwidth; The ETag parameter is also a commonly used cache control parameter to solve the problem of insufficient last-modified time accuracy. In addition, the HTTP protocol has direct support for the Proxy mechanism, in combination with the cache mechanism, in applications that require high performance, a number of caching proxy servers dedicated to cache purposes can be deployed between the server and the client to improve system throughput.

Summary

Finally summarize the rest point: 1.  The URL represents a resource; 2. CRUD operations; 3. State representations are transferred. As for stateless service, HTTP status code, cache control, proxy and so on are the main points of inference, the key to understanding rest is to understand the resource-centric model. This article is I touch rest less than a year of some experience and summary, know the rest of the master and application still need to continue efforts, hope to get expert guidance!

RELATED LINKS

1. How to get a cup of coffee-Starbucks Rest Case study

2. "In Layman's Rest"

Rest architectural Style Introduction II: CRUD