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 (versions 1.0 and 1.1), one of the authors of the Apache server software, and the first chairman 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 The 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 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 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.
Resources Representational State Transfer:
3. Resources
In REST's name "presentation layer state transition", 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)
A "resource" is an information entity that can have many external manifestations. The form in which we specifically present the "resource" is called its "representation 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
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 on the above explanation, let's summarize what is RESTful architecture:
(1) Each URI represents a resource;
(2) Between the client and the server, a certain presentation layer of this resource is transferred;
(3) The client operates the server-side resources through four HTTP verbs to achieve "presentation layer state transformation".
7. Misunderstanding
RESTful architecture has some typical design mistakes.
One of the most common design mistakes is when URIs contain verbs. Because "resource" represents 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 way to write it is to change the verb transfer to the noun transaction. The resource cannot be a verb, but can be a service:
POST /transaction HTTP/1.1
Host: 127.0.0.1
from=1&to=2&amount=500.00
Another design misunderstanding is adding 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
Because different versions can be understood as different representations of the same resource, the same URI should be used. Version numbers 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
(over)
1. 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. Resources always reflect their content through some kind of carrier. Text can be expressed in txt format, HTML format, XML format, or even binary format; pictures can be expressed in JPG format or PNG format; JSON is The most commonly used resource representation format today.
2. Unified interface:
The RESTful architectural style stipulates that the meta-operations of data, namely CRUD (create, read, update and delete, that is, data addition, deletion, query and modification) operations, correspond to HTTP methods respectively: GET is used to obtain resources, POST is used to create new resources (or It is used to update resources), PUT is used to update resources, and DELETE is used to delete resources. This unifies the interface of data operations. Only through HTTP methods, all additions, deletions, and changes to data can be completed.
which is:
- GET (SELECT): Retrieve resource(s) from the server.
- POST (CREATE): Create a new resource on the server.
- PUT (UPDATE): Update the resource on the server (client provides complete resource data).
- PATCH (UPDATE): Update resources on the server (the client provides the resource data that needs to be modified).
- DELETE (DELETE): Deletes the resource from the server.
3. URI: (Uniform Resource Identifier)
A URI (Uniform Resource Identifier) can be used to point to a resource, that is, each URI corresponds to a specific resource. To get this resource, just visit its URI, so the URI becomes the address or identifier of each resource.
A URI identifies an Internet resource with a string, while a URL indicates the location of the resource (where it is located on the Internet). Therefore, URL is a subset of URI.
4. Stateless:
Requests for each resource are addressable, and the availability of that resource does not depend on the availability of some specific resource. What this means here is that a request for a resource does not depend on requests for other resources, and there is at least one URL corresponding to this resource. eg: For example, if I need to check my final grades, I can directly enter a website to check my grades on the browser, and I can get my grades; I don’t need to do login, inquiry and other information. If the login is unsuccessful, I can’t check my grades. .