More and more people are beginning to realize that the website is software, and it is a new type of software.
This kind of 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.
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 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 the paper as follows:
This paper studies the intersection of two major frontiers of computer science—software and networking. For a long time, software research has mainly focused on the classification of software design and the evolution of design methods, and rarely objectively evaluates the impact of different design choices on system behavior. Conversely, network research focuses on the details of the 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 has a greater impact on overall performance than changing the interaction protocol influence.
The purpose of my 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 an architecture with strong functions, good performance and suitable communication.
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.
3. Resources (Resources) In
the name of REST "presentation layer state transformation", the subject is omitted. The "presentation layer" actually refers to the "presentation layer" of "resources" (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 that can have multiple external manifestations. We call the form in which the "resources" concretely presented, 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 the 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 transition" (State Transfer) happen on the server side. And this transformation is based on the presentation layer, so it is "transformation of presentation layer state". .
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 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 passes Four HTTP verbs operate on server-side resources 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" 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 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
Because of different versions, http://www.example.com/app/2.0/foo
can be understood as different representations of the same resource, so 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
Link : https://www.zhihu.com/question/33959971/answer/57593571
Source: Zhihu The
copyright belongs to the author. For commercial reprints, please contact the author for authorization, and for non-commercial reprints, please indicate the source.
The full name of REST is already in the article, the core of which is the first letter R, that is, Resource.
Well the first letter is Representational, but the core is really resources
The core of REST is that when you design a system, resources are the first consideration. You first divide and design the system from the perspective of resources, rather than design from the perspective of operation as before.
Our usual system is like this:
- There is a new user function
- Creating a new user requires a URL
- The data sent to this URL should be defined
- Start writing backend and frontend
This is an operation-first design method. First, we confirm an operation, and then build the surrounding needs around this operation. Of course, this method can build a system, even a good system, but occasionally some problems:
- There will be a relationship between operations, and your design will easily become "the second operation requires the first operation to be performed". If there are more such relationships, your system will be chaotic
- Your URL design will lack consistency
- Operations are generally considered to have side effects, so few people design things like caching based on operations
Based on these problems, our other approach is to do it from the perspective of resources, but this is too difficult. I still don't know how to do it, but there are some benefits based on resources:
- Although each resource may be associated, it is still possible to simply cut off these associations and become independent, so there will be no chaotic coupling.
- There are only so many operations on resources, so it is easy to design consistent URLs
- We understand that read operations on resources have no side effects, so we can play cache
But in fact, 99% of them say that they are REST, that is, they changed the URL style and used PUT and POST. on show
To say that I know REST, I think at least 2 questions should be answered:
- For the two business requirements of user login and user logout, how does the architecture and design under the guidance of REST meet
- How to delete, modify and add in batches
There is no standard answer, different people have different interpretations with their own understanding of REST
For the 1st, my interpretation is to take "login" as a resource, so login is POST /logins, and logout is DELETE /logins
For the second, I tend to set it in a single resource such as (/users is the set of users ) The above engages in a "set of set", so the batch operation is actually a single operation on the "set of set"
