Understanding the RESTful architecture

More and more people are beginning to realize that the website is software, and it is a new kind of software.

This "Internet Software" uses the client/server model, which is built on the distributed system and communicates with the Internet, which has the characteristics of high latency (hi latency) and high concurrency.

Website development, can adopt the model of software development completely. But traditionally, the software and the network are two different fields, seldom have the intersection, the software development is mainly for the single machine environment, the network mainly studies the communication between the system. The rise of the Internet has enabled these two areas to converge, and now we have to consider how to develop the software used in the Internet environment.

The restful architecture is one of the most popular Internet software architectures available. Its structure is clear, conforms to the standard, easy to understand, expands conveniently, therefore is getting more and more website adoption.

However, what is a restful architecture is not an easy question to be clear about. Below, I'll talk about the restful architecture I understand.

First, origin

The word rest is from Roy Thomas Fielding in his 2000 doctoral dissertation.

Fielding is a very important person who is the main designer of the HTTP protocol (version 1.0 and 1.1), one of the authors of the Apache server Software, and the first president of the Apache Foundation. As a result, the publication of his paper has attracted much attention and has had a profound impact on the development of the Internet.

He introduces the purpose of writing this paper:

This paper studies the intersection of two frontier----software and network----of computer science. For a long time, software research focuses on the classification of software design, the evolution of design methods, rarely objectively evaluate the impact of different design choices on system behavior. On the contrary, network research focuses on the details of communication behavior between systems, how to improve the performance of specific communication mechanisms, and often ignores the fact that changing the interactive style of the application is more important than changing the interactive protocol and the overall performance. The purpose of my writing is to understand and evaluate the architecture design of Web-based application software in accordance with the principle of architecture, and to obtain a structure with strong function, good performance and suitable communication. "

(This dissertation explores a junction on the frontiers of the both the disciplines in computer Science:software and NETW Orking. Software have long been concerned with the categorization of software designs and the development of design method Ologies, but had rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking, in contrast, was focused on the details of generic communication behavior between systems and Improvin G The performance of particular communication techniques, often ignoring the fact that changing the interaction style of a N application can has more impact on performance than the communication protocols used for that interaction. My work was motivated by the desire to understand and evaluate the architectural design of network-based application Softwa Re through principled use of architectural constraints, thereby obtaining the functional, performance, and social Properti Es desired of an architecture. )

Second, the name

Fielding his architectural principles of Internet software, named rest, the abbreviation of representational state transfer. My translation of this phrase is "presentation layer State transformation".

If a schema conforms to the rest principle, it is called a restful architecture.

The best way to understand the restful architecture is to understand what the phrase representational state transfer means, and what each word represents. If you understand the name, it's easy to see what kind of design rest is.

III. Resource (resources)

The name of rest, "presentation Layer State Transformation", omits the subject. The "presentation layer" actually refers to the "presentation layer" of resources.

The so-called "resources", is an entity on the network, or is a specific information on the network. It can be a piece of text, a picture, a song, a service, in short, is a concrete reality. You can point to it with a URI (Uniform Resource Locator), and each resource corresponds to a specific URI. To get this resource, access its URI so that the URI becomes the address of each resource or a unique identifier.

The so-called "surfing the Internet" is to interact with a series of "resources" on the Internet and invoke its URI.

Iv. Presentation layer (representation)

A "resource" is an information entity that can have a variety of external representations. We take the form of "resources" specifically, called its "presentation Layer" (representation).

For example, text can be expressed in TXT format, can also be used in HTML format, XML format, JSON format, and even binary format can be used, images can be in JPG format, can also be used in PNG format.

The URI represents only the entity of the resource and does not represent its form. Strictly speaking, some URLs last ". html" suffix is unnecessary, because this suffix name represents the format, which belongs to the "presentation layer" category, and the URI should only represent the location of the "resource". Its specific representation should be specified in the header information of the HTTP request with the Accept and Content-type fields, which is the description of the "presentation layer".

V. State transformation (Transfer)

Accessing a Web site represents an interactive process between the client and the server. In this process, data and state changes are bound to be involved.

The Internet Communication Protocol HTTP protocol is a stateless protocol. This means that all States are saved on the server side. Therefore, if the client wants to operate the server, there must be some way to make the server side "state Transfer". And this transformation is based on the expression layer, so is the "Expression Layer state transformation."

The method that the client uses, can only be the HTTP protocol. Specifically, there are four verbs in the HTTP protocol that represent the mode of operation: GET, POST, PUT, DELETE. They correspond to four basic operations: get is used to get a resource, post is used to create a new resource (and can also be used to update resources), put is used to update resources, and delete is used to delete resources. put is a idempotent method, and post is not. So put for update, post for new more appropriate.

Vi. Summary of

Combining the above explanations, we summarize what a restful architecture is:

(1) Each URI represents a resource;

(2) between the client and the server, the transmission of such resources of some kind of performance layer;

(3) The client through four HTTP verbs, the server-side resources to operate, to achieve "performance layer State transformation."

Seven, misunderstanding

The restful architecture has some typical design pitfalls.

One of the most common design errors is that the URI contains verbs. Because "resource" represents an entity, it should be a noun, the URI should not have verbs, the verb should be placed in the HTTP protocol.

For example, a URI is/POSTS/SHOW/1, where show is a verb, the URI is wrong, the correct wording should be/posts/1, and then the show is represented by a GET method.

If certain actions are not represented by an HTTP verb, you should make the action a resource. such as online remittance, from account 1 to account 2 remittance 500 yuan, the wrong URI is:

Post/accounts/1/transfer/500/to/2

The correct way of writing is to change the verb transfer to a noun transaction, the resource cannot be a verb, but it can be a service:

Post/transaction http/1.1
host:127.0.0.1
　　
from=1&to=2&amount=500.00

Another design mistake is to include the version number in the URI:

Http://www.example.com/app/1.0/foo

Http://www.example.com/app/1.1/foo

Http://www.example.com/app/2.0/foo

Because different versions can be understood as different representations of the same resource, the same URI should be used. The version number can be distinguished in the Accept field of the HTTP request header information (see Versioning REST Services):

Accept:vnd.example-com.foo+json; version=1.0

Accept:vnd.example-com.foo+json; version=1.1

Accept:vnd.example-com.foo+json; version=2.0

According to the Richardson Model (http://martinfowler.com/articles/richardsonMaturityModel.html), the rest architecture has a maturity of 3 levels:
Level 0 POX (this is not rest)
Level 1 Resources
Level 2 Http Verbs
Level 3 Hypermedia Controls

The model presented by the landlord is at Level 2, which is also the maturity of most restful applications at present.

Level 0 POX
Such applications have only one God interface on the URI, and all resources are manipulated based on the XML content being exchanged. Often leads to an increasingly complex interface between God and more difficult to maintain.

Level 1 Resources
This level mainly solves the problem of God interface, so that all kinds of resources have their own corresponding URI, although still is pox interactive way, but each interface is more compact and cohesive, the corresponding easy maintenance up.
The main problem here is URI templating and URI tunneling.
The result of URI templating is the tight coupling between the server side and the client, and any time the server segment wants to change its URL schema, it must break the existing client application.
The problem with URI tunneling includes URI templating, and discards any benefits of using the HTTP protocol standard, as detailed in Level 2.
The early rails routes were URL templating/tunneling. The RAILS3 is already closer to level 2.

Level 2 Http Verbs
This level uses HTTP verbs to perform CRUD operations on various resources, making the interface of the application more uniform and semantically more explicit. At the same time, many of the benefits of HTTP are almost free due to interacting with HTTP standards.

1. Cache
In accordance with the HTTP protocol, get operations are secure, idempotent (idempotent). Any multiple get operations on the same resource do not cause a change in the state of the resource. So the result of get is safe to cache. All HTTP-provided cache facilities can be leveraged to dramatically improve application performance. Even if you just add the cache directives to the response, you get free cache support for all levels of the network, proxy servers, and user clients. Almost all applications on the Internet you can roughly count the ratio of get VS non-get requests to about 4:1. If you can add a cache to a get operation, that will greatly provide the performance of your program.
2. Robust
In several verbs commonly used in HTTP, HEAD, GET, PUT, DELETE are safe, idempotent, and so on. Because any number of requests to the same resource always represent the same semantics. So any time the client sends out these verbs, if the server is not responding, or if the error code is returned, the client can perform the same operation again without worrying about the different semantics and end result of the repeated operation. Post, the patch operation is not secure because the client is not able to repeat operations safely when the server does not respond or returns an error code after the client makes a request to the server. You must only re-confirm the current resource status with the server to decide what to do next.

The vast majority of restful applications are parked here and, of course, satisfy most of the needs.

Level 3
The restful architecture is intended to "understand and evaluate the architecture design of network-based application software in accordance with the principles of architecture, and get a powerful, well-performing and suitable architecture for communication." "
What is the world's largest, least-coupled, most stable, and best-performing distributed network application? is the web itself.
Scale, stability, performance are needless to say. Why is it that the coupling degree is low? Think about the experience of everyone on the Internet, you almost do not need any training on a new online shopping platform to select goods, credit card payment, mailed to their home.
Think of the site's program as a state machine, where users accomplish their goals in a series of state transitions. Each of these steps, the application tells you the current state and possible next steps, and ultimately leads the user to pick a product, select more items, go to the Payment page, enter the credit card information, and finally complete the payment to reach the end of the state machine.

This service discoverablility and self-documenting is what level 3 wants to solve.

In this case, tell the user the current state and various next things, such as links, buttons and so on, is Hypermedia Controls. Hypermedia Controls is the engine of this state machine.

The rest architecture of Level 3 is the desire to unify this type of hypermedia Controls, giving them the standard, highly extensible standard semantics and manifestations that make it possible for even the common interaction protocol edge between machines and machines that are unmanned to intervene. For example, you can tell a generic shopping client, "Buy me the cheapest Xbox", the client automatically connect Google to search, automatically search on the top 10 shopping sites, price sequencing, and then automatically pick the cheapest site, a series of operations to complete the final payment by credit card, Fill in your personal pickup address and mail it.

These depend on the service discoverablility and self-documenting that hypermedia controls bring

For more details on rest and its application and implementation, refer to rest in practice. A very, very good book, the rest is very thorough.

Understanding RESTful schemas