Understand the RESTful architecture

More and more people are beginning to realize that websites are software and a new type of software.

This “Internet software” adopts the client/server model, is built on a distributed system, communicates over the Internet, and has the characteristics of high latency and high concurrency.

Website development, it is entirely possible to adopt a software development model. But traditionally, software and networks are two different fields, with few intersections; software development is mainly for stand-alone environments, and networks are mainly for communication between systems. The rise of the Internet has led to the convergence of these two areas, and now we must consider how to develop software for use in the Internet environment.

The RESTful architecture is currently the most popular Internet software architecture. It is well-structured, standards-compliant, easy to understand, and easy to expand, so it is getting more and more websites.

However, what is a RESTful architecture is not an easy question to explain. Below, I will talk about the RESTful architecture I understand.

First, the origin

The word REST was coined by Roy Thomas Fielding in his 2000 doctoral thesis .

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. Therefore, once this paper was published, it attracted attention and immediately had a profound impact on Internet development.

He introduced the purpose of writing the thesis:

“This paper studies the intersection of two frontiers of computer science — — software and network — -. Software research has long focused on the classification of software design, the evolution of design methods, and rarely objectively evaluate different design choices. The impact of system behavior. Conversely, network research focuses on the details of communication behavior between systems, how to improve the performance of specific communication mechanisms, often overlooking the fact that changing the interactive style of the application is more than changing the interactive protocol. The table has a greater impact. The purpose of this article is to understand and evaluate the architecture design of network-based applications under the premise of conforming to the architectural principles, to obtain a powerful, good performance, and suitable communication. Architecture.
(The 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 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 and and 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.

Second, the name

Fielding named his architectural principles for Internet software REST, the abbreviation of Representational State Transfer. My translation of this phrase is “transformation state transition.”

If an architecture conforms to REST principles, 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 of its words represents. If you understand the name, it is not difficult to understand what kind of design REST is.

Third, resources (Resources)

In the name of the REST “presentation level state conversion”, the subject is omitted. “Expression layer” actually refers to the “representation 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), each resource corresponding to a specific URI. To get this resource, access its URI, so the URI becomes the address of each resource or a unique identifier.

The so-called “online” is to interact with a series of “resources” on the Internet and call its URI.

Fourth, the performance layer (Representation)

A “resource” is an information entity that can have multiple external manifestations. The form in which we present the “resources” is called its “representation”.

For example, text can be expressed in txt format, or in HTML format, XML format, JSON format, or even binary format; images can be expressed in JPG format or PNG format.

A URI represents only the entity of a resource and does not represent its form. Strictly speaking, the last “.html” suffix of some URLs is unnecessary, because this suffix represents the format, which belongs to the “presentation layer” category, and the URI should only represent the location of the “resource”. Its concrete manifestation should be specified in the header of the HTTP request with the Accept and Content-Type fields. These two fields are the descriptions of the “presentation layer”.

Fifth, state transfer (State Transfer)

Accessing a website represents an interactive process between the client and the server. In this process, it is bound to involve changes in data and state.

The Internet Protocol HTTP protocol is a stateless protocol. This means that all state is saved on the server side. Therefore, if the client wants to operate the server, there must be some means to cause “State Transfer” on the server side. And this transformation is based on the presentation layer, so it is the “expression 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 represent the operation mode: GET, POST, PUT, and DELETE. They correspond to four basic operations: GET is used to obtain resources, POST is used to create new resources (also used to update resources), PUT is used to update resources, and DELETE is used to delete resources.

Six, review

Based on the above explanation, let’s summarize what a RESTful architecture is:

(1) Each URI represents a resource;

(2) A representation layer that conveys such resources between the client and the server;

(3) The client operates on the server-side resources through four HTTP verbs to implement “expression layer state conversion”.

Seven, misunderstanding

The RESTful architecture has some typical design pitfalls.

One of the most common design mistakes is that URIs contain verbs. Because “resources” represent an entity, it should be a noun, the URI should not have a verb, and the verb should be placed in the HTTP protocol.

For example, a URI is /posts/show/1, where show is a verb, and the URI is wrongly designed. The correct wording should be /posts/1, and then use GET to indicate show.

If some actions are not represented by HTTP verbs, you should make the action a resource. For example, online remittance, remit 500 yuan from account 1 to account 2, the wrong URI is:

POST /accounts/1/transfer/500/to/2

The correct way to write 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 misunderstanding 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

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 (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

(Finish)