Rest architecture style Introduction: Status transition

This article summarizes some experience in designing a rest-style architecture, introduces the language ecosystem of the rest architecture, status expression transfer, stateless server, and other features, google is used as an example to illustrate the REST style.

Rest (representational state transfer) is an Internet application architecture style proposed by Roy Fielding, an HTTP protocol author, in his doctoral thesis. Compared with the remote object-centered orb and service-oriented SOA, resource-centric rest allows us to examine Internet applications from a new perspective. The simple model customized by rest for Internet applications, perfect combination with HTTP protocol, and high architecture scalability bring fresh air to the Internet application architecture design and heterogeneous system integration design.

Language ecosystem environment

Since the development of computers, many different languages have emerged. Each Language defines its own unique ecological environment. In this ecological environmentProgramShare the same type system, runtime environment, and concurrency model. Although the nature of all programs is the same: From the problem field to the machine field ing, what cannot be avoided is that programs in different ecological environments are difficult to cross their boundaries. The same is int, which is usually quite different in languages A and B (CLR and JVM can partially solve the type sharing problem ), not to mention that language A has some language features that language B does not have (CLR and JVM cannot solve ).

When a system can be self-sufficient in a single ecosystem, the problem of crossing the ecosystem does not exist. However, in most Internet applications, all parts of the system are both producers and consumers, it is necessary to break the boundaries of the ecosystem to collaborate with each other. For example, service a of Company A needs to provide external services, and service a depends on service B of Company B and service C of Company C; since different companies cannot use the same language, the interfaces of various services must ensure language independence. In my understanding, there are three cross-origin ecological environments:

1. Orb (Object Request Broker)
The core concept of this architecture is remote object, represented by CORBA ). Friends familiar with. Net remoting should be able to understand their style (it should be noted that. Net remoting only spans the Microsoft ecosystem environment ). Programs in different ecological environments can call remote object proxy methods just like local objects. Orb is responsible for connecting to remote objects and processing data serialization and deserialization.

2. SOA

Its core concept is service ). For example, if we want to provide the integer addition Web service, we naturally think of expressing the service interface through a URL similar to the following:

Http://www.example.com/add? A = 1 & B = 2

And express the results through XML structure

3. Rest

Its core concept is resource ). In the rest of the world, there is no service concept, the same is the above example, in the rest of the world, http://www.example.com/add? A = 1 & B = 2 is the ID of an XML webpage resource, rather than the service interface. So rest allows us to examine Internet applications from the perspective of resources and guide our design. This is the essential difference between it and ORB and SOA. The following describes in detail the rest resource-centric model and the corresponding design style.

Status transition

In the rest world, resources are state, while the Internet is a huge state machine. Each web page is a state, and a URL is a state statement; rest-style applications migrate from one State to the next state. When there were only static pages on the Internet in the early days, the page to jump between static webpages through hyperlinks-> link-> page-> link... Mode is a typical state transfer process.

Stateless Server

Rest-style applications can achieve interaction, but they naturally have the serverless stateless features. During Status migration, the server does not need to record any sessions. All statuses are recorded on the client through URLs. PS: more accurately, the stateless server here means that the server does not save the session state (Session), and the resource itself is a natural state, which usually needs to be saved; the stateless server mentioned in this Article refers to the non-session server.

 

For example, a user needs to make two multiple-choice questions for a psychological test application. Each time A and B are selected, the user will be informed of the psychological type after the two choices are completed.

If we follow the service thinking of ORB or SOA, it is easy to think of saving the session on the server side, changing the session after each selection, and generating results based on the session. However, guided by the rest state expression transfer model, we will naturally come up with the following design:

 

Each page indicates a status (which exists on the client). The page contains a hyperlink to the next page. Each time you select A or B, the page is transferred to the next status. In this way, all session statuses are saved on the client in the form of URLs, and stateless on the server side. In addition, it should be noted that although there are 7 statuses, it is not necessary to generate 7 static pages on the server in advance, they can be dynamic pages, this does not affect the concept model of State transfer and the stateless features of servers.

 

Those with architectural design experience should be clear that compared with stateful service design, stateless services can easily achieve horizontal scaling of system performance. By adding hardware, deploying multiple stateless services and load balance will not be restricted. However, in stateful service mode, session storage and sharing will bring performance bottlenecks, and cannot be eliminated by adding hardware.

Google search is a typical stateless service. After you search for Jay Chou, Google prompts you millions of results and divides each 10 pages into several pages. Will Google Save the results to the server session, then, when you flip the page, will you retrieve it from the session? Obviously, even Google cannot afford such a huge session. Let's take a look at Google's URL:
Page 1:

Http://www.google.cn/search? Q = % E5 % 91% A8 % E6 % 9d % B0 % E4 % BC % A6 &; HL = ZH-CN & newwindow = 1 & START = 0 & SA = N
Page 2: http://www.google.cn/search? Q = % E5 % 91% A8 % E6 % 9d % B0 % E4 % BC % A6 &; HL = ZH-CN & newwindow = 1 & START = 10 & SA = N

Google regards each page of the search result as a resource (Status) and uses a URL. Different pages with the same search keyword are differentiated by the start parameter. When you click the link on the second page on the first page, you just jump from a State to the next state. for Google, it is actually a new query (according to rest, and the two queries may be processed by different servers, but the user feels that Google remembers the session.

From the above example, we initially experienced a bit of rest style taste. However, it should be noted that the REST style contains the features of stateless servers, but in turn, rest is not the feature of stateless servers. SOA can also be stateless. The core of rest is still resources.