To understand the restful Architecture

More and more people begin to realize that,Websites are software and a new type of software.

This "Internet software" adopts the Client/Server mode and is built on a distributed system. It communicates over the Internet, featuring high latency and high concurrency.

Website development can fully adopt the software development mode. However, traditionally, software and network are two different fields, with few intersections. Software Development focuses on standalone environments, while networks focus on communication between systems. The rise of the Internet has combined these two fields. Now we must consider how to develop software used in the Internet environment.

Restful architecture is currently the most popular Internet software architecture. It has a clear structure, complies with standards, is easy to understand, and is easy to expand, so it is being adopted by more and more websites.

However, what is a restful architecture is not a clear question. Next, let's talk about the restful architecture that I understand.

I. Origin

The word rest was proposed by Roy Thomas Fielding in his doctoral thesis in 2000.

Fielding is a very important person. He is the main designer of HTTP (1.0 and 1.1), one of the authors of Apache server software, and the first Chairman of the Apache Foundation. Therefore, his paper was published and immediately had a profound impact on Internet development.

He introduced the purpose of writing the paper as follows:

"This article studies the intersection of the two cutting-edge computer science-software and network. For a long time, software research has focused on the classification of software design and the evolution of design methods, and seldom objectively evaluates the impact of different design choices on system behavior. On the contrary, network research focuses on the details of Inter-System Communication Behaviors and how to improve the performance of specific communication mechanisms, which often ignores the fact that, that is, changing the interaction style of an application has a greater impact on the overall performance than changing the interaction protocol. The purpose of this article is to understand and evaluate the architecture design of network-based application software on the premise of complying with the architecture principles, A architecture with strong functions, good performance, and suitable for communication is available. "

(This dissertation takes es 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 particle 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 specified tural design of network-based application software through principled use of specified tural constraints, thereby obtaining the functional, performance, and social properties desired of an architecture .)

Ii. Name

Fielding named his Architecture Principles for Internet software as rest, short for representational state transfer. My translation of this phrase is "transition of the presentation layer state ".

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

To understand the restful architecture, the best way is to understand what the phrase representational state transfer actually means and what each word represents. If you understand the name, it is not difficult to understand what a rest design is.

Iii. Resources)

The subject is omitted in the rest name "transition of the presentation layer status. The "presentation layer" actually refers to the "presentation layer" of "resources ".

The so-called "resource" refers to an entity on the network, or a specific information on the network. It can be a piece of text, an image, a song, a service. In short, it is a specific reality. You can use a Uniform Resource Identifier (URI) to point to it. Each resource corresponds to a specific URI. To obtain this resource, you can access its URI. Therefore, Uri becomes the address or unique identifier of each resource.

The so-called "surfing the Internet" means interacting with a series of "Resources" on the Internet and calling its Uri.

4. Representation)

"Resource" is an information entity that can have multiple external forms. The specific representation of "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. images can be expressed in JPG format, it can also be expressed in PNG format.

Uri only represents the entity of a resource, not its form. Strictly speaking, some URLs last ". html "suffix name is unnecessary because the suffix name represents the format and belongs to the category of" presentation layer ", and Uri should only represent the location of" resource. Its specific manifestation should be specified with the accept and Content-Type fields in the HTTP request header information. These two fields are the description of the "presentation layer.

5. State Transfer)

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

HTTP is a stateless protocol. This means that all statuses are saved on the server. Therefore, if the client wants to operate the server, it must use some means to make the server "state transition" (State transfer ). This transformation is built on the presentation layer, so it is "performance Layer state conversion ".

The client can only use HTTP. Specifically, there are four verbs in the HTTP protocol indicating the operation method: Get, post, put, and delete. They correspond to four basic operations: Get for obtaining resources, post for creating resources (or for updating resources), put for updating resources, and delete for deleting resources.

Vi. Summary

Based on the above explanation, let's summarize what the restful architecture is:

(1) Each URI represents a resource;

(2) A performance Layer for transferring such resources between the client and the server;

(3) The client uses four HTTP verbs to perform operations on server resources and realize "transition of performance Layer status ".

VII. misunderstandings

The Restful architecture has some typical design mistakes.

The most common design error is that Uri contains verbs. Because "resource" represents an entity, it should be a noun. Uri should not have a verb, and the verb should be placed in the HTTP protocol.

For example, if a URI is/posts/show/1 and show is a verb, This URI is designed incorrectly. The correct method is/posts/1, then, use the get method to represent show.

If some actions cannot be expressed by HTTP verbs, you should make the actions a resource. For example, for online remittance, 500 yuan is transferred from account 1 to account 2. The error URI is:

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

The correct syntax is to change the verb transfer to the noun transaction. A 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 the version number to 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

(End)

 

From: http://www.ruanyifeng.com/blog/2011/09/restful.html

An article:

Literate programming-nobody understands rest or HTTP

This article is very interesting. It explores the depth of rest and particularly highlights the concept of rest URL.

For example, for bank transfers, transfer from account 1 to account 2 to transfer 500 yuan, the rest URL is generally written:
Post/accounts/1/transfer/500.00/to/2

Actually, it is wrong because R in rest represents resource resources, and resource is a term. You are not transferring money, but creating a transfer transaction resource. It should be:

Post resource term

This concept is very interesting. We know thatDddIt is also a noun modeling, inDddIn, transfer transactions are implemented using a service. Of course, the service here can be regarded as a resource.

One article once thought that web is inherently function-oriented. Here, "Post" can be regarded as a method function, while "resource noun" can be regarded as a method parameter.

Is there a Technical Idea in the future?DddThe rest and function-oriented functions are perfectly bundled together. The URL represents the structural relationship of the domain model class graph, for example,/FORUM/thread, representing the subclass thread of the Forum class, domain Models are explicitly expressed using URLs. User Access forms are combined with the models we designed for analysis.

I think too much about it. Back in this article, the author thinks that this transfer should be to create a transfer transaction resource and change it:

Post/transactions

Then add the parameter from = 1 & to = 2 & amount = 500.00

In function-oriented FP, functions can also be considered as an object, that is, resources. In rest, they seem to have been unified.

Next, the author thinks that after a transaction resource is created, the server rest end will return:

HTTP/1.1 201 OK Date: Sun, 3 Jul 2011 23:59:59 GMT Content-Type: Application/JSON Content-Length: 12345 Location: http:// Foo.com/transactions/1 {"Transaction": {"ID": 1, "Uri": "/transactions/1 "}}

The returned URL is response.

When the rest client re-accesses:
GET/transcoding/1 HTTP/1.1

The returned result is:
HTTP/1.1 blah

{"ID": 1, "status": "in-progress "}

Processing. We can continue to access this URL until it is completed or failed. This is the concept of nouns.

Some people may think that the concept of this term is contrary to the native function FP of the web. In fact, the rest post/get and other four actions have already indicated that they are functions, so the URL undoubtedly represents the business term. Of course, can a URL represent a business method or function? In fact, transactions are treated as resources, and transactions are clearly business methods or functions.