Understand Restful style architecture

More and more people are beginning to realize that the website is software, and it is a new type of software.
This "Internet software" adopts the client/server model, is built on a distributed system, communicates through the Internet, and has the characteristics of high latency and high concurrency.
Web site development, can use the software development model. But traditionally, software and networking are two distinct fields with little intersection; software development is mainly for a stand-alone environment, while networking is the study of communication between systems. The rise of the Internet has brought these two fields together, and now we must consider how to develop software for use in the Internet environment.

RESTful architecture is currently the most popular Internet software architecture. It has a clear structure, conforms to standards, is easy to understand, and is easy to expand, so it is being adopted by more and more websites.
However, what exactly is a RESTful architecture is not an easy question to articulate. Next, I will talk about the RESTful architecture as I understand it.
1. Origin
The term REST was coined by Roy Thomas Fielding in his doctoral dissertation in 2000.

Fielding is a very important person, he 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 CEO of the Apache Foundation. So, as soon as his paper was published, it attracted attention and had an immediate and far-reaching impact on Internet development.
He described the purpose of writing the paper as follows:
"This paper examines the intersection of two major frontiers in computer science—software and networking. For a long time, software research has primarily focused on the classification of software design, the evolution of design methods, and rarely objectively evaluates the impact of different design choices on the In contrast, network research focuses on the details of communication behavior between systems and how to improve the performance of a particular communication mechanism, often ignoring the fact that changing the interaction style of an application is more important than changing the interaction protocol for the whole Performance has a greater impact. The purpose of writing this article is to understand and evaluate the architecture design of network-based application software under the premise of conforming to the principles of architecture, so as to obtain a powerful, high-performance and suitable communication software. Architecture."
(This dissertation explores a junction on the frontiers of two research disciplines in computer science: software and networking. Software research has long been concerned with the categorization of software designs and the development of design methodologies, but has rarely been able to objectively evaluate the impact of various design choices on system behavior. Networking research, in contrast, is focused on the details of generic communication behavior between systems and improving the performance of particular communication techniques, often ignoring the fact that changing the interaction style of an application can have more impact on performance than the communication protocols used for that interaction.My work is motivated by the desire to understand and evaluate the architectural design of network-based application software through principled use of architectural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture. )
2. Name
Fielding named his architectural principles for Internet software as REST, short for Representational State Transfer. My translation of this phrase is "presentation-level state transition".
If an architecture conforms to REST principles, it is called a RESTful architecture.
The best way to understand RESTful architecture is to understand what the phrase Representational State Transfer really means and what each of its words means. If you understand the name, it is not difficult to understand what kind of design REST is.
3. Resources (Resources) In
the name of REST "state transformation of presentation layer", the subject is omitted. The "presentation layer" actually refers to the "presentation layer" of "Resources".
The so-called "resource" is an entity on the network, or a specific information on the network. It can be a piece of text, a picture, a song, a service, in short 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, just visit its URI, so the URI becomes the address or unique identifier for each resource.
The so-called "surfing the Internet" means interacting with a series of "resources" on the Internet and calling its URI.
Fourth, the presentation layer (Representation)
"Resource" is an information entity, it can have a variety of external manifestations. The form in which we specifically present "resources" is called its "presentation layer" (Representation).
For example, text can be expressed in txt format, HTML format, XML format, JSON format, or even binary format; pictures can be expressed in JPG format or PNG format.
The URI only represents the entity of the resource, not its form. Strictly speaking, the ".html" suffix name at the end of some URLs is unnecessary, because this suffix name indicates the format and belongs to the category of "presentation layer", and URI should only represent the location of "resource". Its specific form should be specified by the Accept and Content-Type fields in the header information of the HTTP request. These two fields are the description of the "presentation layer".
5. State Transfer (State Transfer)
Visiting a website 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, all state is kept on the server side. Therefore, if the client wants to operate the server, it must use some means to make the "State Transfer" happen on the server side. And this transformation is based on the presentation layer, so it is "presentation layer state transformation".
The means used by the client can only be the HTTP protocol. Specifically, in the HTTP protocol, there are four verbs that express the operation mode: GET, POST, PUT, DELETE. They correspond to four basic operations: GET is used to obtain resources, POST is used to create new resources (and can also be used to update resources), PUT is used to update resources, and DELETE is used to delete resources.
6. Overview
Based the above explanations, we summarize what is RESTful architecture:
　　(1) Each URI represents a resource;
　　(2) Between the client and the server, a certain presentation layer for transferring this resource;
　　(3) The client operates on server-side resources through four HTTP verbs to achieve "presentation layer state transformation".
7. Mistakes
RESTful architecture has some typical design mistakes.
One of the most common design mistakes is when URIs contain verbs. Because "resource" means an entity, it should be a noun, URIs should not have verbs, and verbs should be placed in the HTTP protocol.
For example, a URI is /posts/show/1, where show is a verb, this URI is wrongly designed, the correct writing should be /posts/1, and then use the GET method to indicate show.
If some action cannot be expressed by HTTP verbs, you should make the action a resource. For example, online remittance, remittance 500 yuan from account 1 to account 2, the wrong URI is:
　　POST /accounts/1/transfer/500/to/2
The correct spelling is to change the verb transfer to the noun transaction, resources cannot be verbs, 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 add a version number to 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
can be understood as different representations of the same resource because of different versions, so it should be Take the same URI. The version number can be distinguished in the Accept field of the HTTP request header (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

本文转自http://www.ruanyifeng.com/blog/2011/09/restful.html