Rest architectural Style Introduction: state representation transfer

Reprinted from: Todd Wei http://www.cnblogs.com/weidagang2046/archive/2009/05/08/1452322.html

REST (representational state Transfer) is an Internet application architecture style presented by Dr. Roy Fielding, author of the HTTP protocol, in his doctoral dissertation. Resource-centric rest allows us to look at Internet applications from a new perspective, compared to an orb with a remote object at its core and a service-centric SOA. Rest for the Internet application of a simple model tailored to the perfect combination of HTTP protocol, the architecture of high scalability, for the Internet application Architecture design and heterogeneous system integration design brings a fresh air.

This article hopes to share with you the experience of rest style architecture design, the error is not enough to welcome criticism.

Language ecological Environment

Since the development of computer, many different languages have been produced, each of which defines its own unique ecological environment. Programs within the same ecosystem share the same type system, runtime environment, concurrency model, and so on. Although the nature of all programs is the same: from problem areas to machine domain mapping, it is not possible to avoid the different ecological environment of the program is difficult to cross each other's boundaries. also int, in A and B languages are usually quite different (CLR and JVM can partially solve type-sharing problems), not to mention some language features that a language has but does not have in B language (CLR and JVM cannot solve).

When the system can be self-sufficient in a single ecological environment, the problem of cross-ecological environment does not exist, but in most Internet applications, the parts of the system are usually both producer and consumer, and must break the boundary of ecological environment to cooperate. For example, service A of company a needs to provide services externally, and service a relies on service C of service B and Company C of Company B; Because there is no guarantee that different companies will use the same language, the interfaces of each service must ensure language independence. Within the scope of what I know, there are 3 ways to cross-domain eco-environments:

1. ORB (Object Request Broker)

As the representative of CORBA, the core concept is the remote object. A friend familiar with. NET remoting should be able to appreciate its style (it should be explained that. NET remoting only spans Microsoft's ecosystem). Different eco-environment programs can invoke the remote object proxy like a local object, and the orb is responsible for connecting to the remote object and processing the serialization and deserialization of the data.

2. SOA

The core concept is service. For example, we would like to provide an integer addition Web service, and it would be natural to expect to express the service interface by a URL similar to the following:

http://www.example.com/add?a=1&b=2

And the result is expressed through the XML structure:

<sum>3</sum>

3. REST

Its core concept is resources (Resource). In the rest world, there is no concept of service, also the above example, in the rest world, http://www.example.com/add?a=1&b=2 is the ID of an XML Web page resource, not the interface of the service. So, rest lets us look at the Internet application from a resource perspective and guide our design, which is the most essential difference between it and the Orb and SOA. The following is a more detailed introduction to the resource-centric model of rest and the corresponding design style.

State representation transfer

In the rest world, resources are state, and the Internet is a huge state machine: Each page is a state; a URL is a state representation; a rest-style application is a state transfer process that migrates from one state to the next. The early Internet only static pages, through the hyperlinks in the static web browsing between the jump Page->link->page->link ... Pattern is a typical state transfer process.

Stateless Server

Rest-style apps can interact, but they naturally have server-stateless features. In the process of State migration, the server does not need to log any session, all the state is logged in the form of a URL in the client. PS: More accurately, the stateless server here refers to the server does not save session state (sessions), and the resources themselves are natural state, usually need to be saved; The stateless server mentioned in this article refers to a non-session-state server.

For example: The application of a psychological test, users need to do 2 times the choice of questions, each can choose a, b two answers, 2 times after the selection will tell the user what kind of psychological type.

If you press ORB or SOA service thinking, it is easy to think of the server-side save session, each time you choose to modify the session, according to the session to produce results. But if we are guided by the rest state representation transfer model, we will naturally draw the following design:

Each page represents a state (present in the client), and the page contains a hyperlink to the next page, each time the user has chosen A or B to move to the next corresponding state. In this way, all the session state is actually stored in the form of a URL in the client, server-side implementation stateless. Also, it is important to note that, although there are 7 states, it is not necessary to pre-generate 7 static pages in the server, they can be dynamic pages, which does not affect the concept model of state transition and the characteristics of server stateless.

A friend with architectural design experience should be aware that, compared with stateful service design, stateless services can easily achieve the lateral scalability of system performance. By adding hardware, deploying multiple stateless services, and load balance are not constrained, while stateful service mode, session storage, sharing will bring performance bottlenecks, and can not be increased by hardware elimination. There is a stateful client behind the stateless server, and because rest keeps all states on the client, there is a certain security risk, which is also the industry's main concern for rest. Therefore, before deciding whether to adopt the rest-style architecture, it should be based on the characteristics of the application itself, including comprehensive scalability, interactivity, security and other factors.

Google search is a typical stateless service. Imagine that when you search for "Jay Chou" after Google prompted you to have millions of results, and every 10 pages into several pages, Google will save the results into the server session, and then when you turn the page, and then from the session to take it? Obviously such a huge session, even Google can not bear. Take a look at Google's URL:

First page: http://www.google.cn/search?q=%E5%91%A8%E6%9D%B0%E4%BC%A6&hl=zh-CN&newwindow=1&start=0&sa= N

Second page: 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 treats each page of the search results as a resource (status) and is represented by a URL, and different pages of the same search keyword are differentiated by the start parameter. When you click on the second page link from the first page, you just jump from one state to the next, and for Google, it's a new query (in terms of rest, getting new resources), and two queries are probably handled by different servers. But users feel that Google seems to remember the conversation.

From the example above, we initially experienced a bit of restful flavor. It is necessary to note that the rest style contains the characteristics of a stateless server, but in turn, not having a stateless server feature is rest. SOA can also be stateless, rest of the core or resources, the next section will continue to discuss this topic, thank you for your attention!

Rest architectural Style Introduction: state representation transfer