Interface specifications and usage guidelines in the rest Architecture

 

The rest architecture is a brand new development style for Web applications. It is the most successful distributed system architecture of Internet hypermedia in the world today. It makes people really understand the original appearance of the HTTP protocol. As the rest architecture becomes the mainstream technology, a brand new way of thinking for Internet network application development has become popular.

Currently, 51, in-school, domestic, and Alibaba software all use the rest architecture to open platform data and exchange data with third parties. Rest has become the primary open standard for the SNS open platform. The following describes the principles and guidelines of rest.

Wiki introduction see this: http://en.wikipedia.org/wiki/Representational_State_Transfer

What is rest?

Rest is the abbreviation of representational state transfer ", he is a term proposed by Dr. Roy Thomas Fielding in his paper titled neural tural styles and the design of network-based software ubuntures. Rest itself is only an architectural style designed for Distributed hypermedia systems, rather than a standard.

The web-based architecture is actually a collection of various specifications, which constitute a Web architecture. For example, the HTTP protocol, such as the client server mode, all of these are standards. Every time we add new specifications on the basis of the original specifications, a new architecture will be formed. While rest is such an architecture, which combines a series of specifications to form a new web-based architecture style.

Most traditional Web applications use the B/S architecture, which includes the following specifications.

Customer-Server

This specification improves the portability of user interfaces across multiple platforms, simplifies server components, and improves system scalability. The most important thing is to separate user interfaces and data storage, so that different user terminals can enjoy the same data.

Stateless

Stateless is another layer of specification added Based on Customer-server constraints. Communication is essentially stateless, that is, every request from the customer to the server must contain all the information required to understand the request. This specification improves the visibility of the system (stateless makes it unnecessary for the client and server to save the detailed information of the other party, and the server only needs to process the current request without having to know all the request history ), reliability (stateless reduces the number of tasks that the server can recover from a local error), scalability (stateless allows the server to easily release resources, because the server does not have to save the status in multiple requests ). At the same time, the disadvantage of this specification is also obvious, because the status data cannot be stored in the sharing on the server.
As a result, the overhead of sending duplicate data in a series of requests is greatly reduced.
Cache

To improve the inefficiency of the stateless network, we have added cache constraints. Cache constraints allow you to implicitly or explicitly mark data in a response, so that the client can cache the response data, so that you can share the cached data for future requests, partially or entirely eliminates some interactions, increasing network efficiency. However, the information cached by the client increases the possibility of inconsistency between the client and the server, thus reducing the reliability.

The advantage of the B/S architecture is that its deployment is very convenient, but it is not ideal in terms of user experience. To improve this situation, we introduced rest.

Rest adds three new specifications to the original architecture: unified interfaces, hierarchical systems, and on-demand code.

Unified Interface

The core feature of the rest architecture style is to emphasize that there is a unified interface between components. This is manifested in the rest world, and all things on the network are abstracted as resources, while rest is to operate resources through a common linker interface. The benefit of this design is to ensure that the services provided by the system are decoupled, greatly simplifying the system, thus improving the system interaction and reusability. In addition, rest is optimized for common web conditions, so that the rest interface is designed to efficiently transfer large-granularity hypermedia data, this causes the rest interface to be not optimal for other architectures.

Layered System

The addition of hierarchical system rules improves the independence between various layers, sets boundaries for the complexity of the entire system, and encapsulates legacy services to protect new servers from the influence of legacy clients, this improves the scalability of the system.

On-demand code

Rest allows extension of client functions. For example, you can download and execute code in the form of an applet or script to expand the client functions. However, this also reduces visibility while improving system scalability. Therefore, it is only an optional constraint of rest.

Rest Design Guidelines

The rest architecture is designed for web applications to reduce development complexity and improve system scalability. Rest proposes the following design principles:

Everything on the network is abstracted as a resource );
Each resource corresponds to a unique resource identifier );
Operate resources through the general connector interface (generic connector Interface;
Operations on resources do not change resource identifiers;
All operations are stateless ).
Resources in rest refer not to data, but to a combination of data and representations, for example, the "10 most recently accessed members" and "10 most active members" may overlap or be identical in data, but because of their different forms, so it is classified into different resources, which is why the full name of rest is representational state transfer. The resource identifier is the URI (Uniform Resource Identifier), whether it is an image, word, video file, or even a virtual service, whether you are in XML format, the TXT file or other file formats are all uniquely identified by Uris.

Rest is based on HTTP, and any operations on resources are implemented through HTTP. In the past, most web development used the get and post methods in the HTTP protocol, and rarely used other methods. This is actually caused by one-sided understanding of the HTTP protocol. HTTP is not only a simple protocol for carrying data, but also a network software with rich connotations. It not only uniquely identifies Internet resources, but also shows us how to operate these resources. HTTP limits the operation on a resource to four methods: Get, post, put, and delete. This is the implementation of resource crud operations. Because resources correspond to Uris one by one, the URI does not change during these operations.
There are many differences in Web development. This greatly simplifies web development and allows the URI to be designed to reflect the resource structure more intuitively. This URI design is called a restful Uri. The developer introduced a new way of thinking: designing the system structure through URLs. Of course, this design method is not applicable to some specific situations, that is, not all Uris can be restful.

Rest can improve system scalability because it requires that all operations are stateless. Without context constraints, it is easier to implement distributed and cluster operations, and the system can use the buffer pool more effectively ). In addition, the server does not need to record a series of client accesses, which reduces the performance of the server.

Use rest Architecture

For developers, they are concerned about how to use the rest architecture. Here we will briefly discuss this issue. Rest is not only a new architecture, but also a new way of thinking in the Web development process: designing the system structure through URL. In rest, all URLs correspond to resources. As long as the URL design is good, the presented system structure is also good. This is similar to test driven development. It designs system interfaces through test cases. Each test case represents a series of user requirements. Developers do not need to write functions at the beginning, but only need to present the functions to be implemented in the form of test cases. This is similar to the way in rest to design the system structure through URL. We only need to design a reasonable URL as needed.
URLs do not have to be linked to a specified page or complete some actions, as long as they can intuitively display the system's user interfaces. Based on these URLs, we can easily design the system structure. From the concept of the rest architecture, everything that can be abstracted into resources can be designated as a URL. What developers need to do is to abstract user requirements into resources, and how to extract images accurately. Because the more accurate the resource abstraction, the better the rest application. This is very different from the action-based idea in traditional MVC development models. A well-designed URL not only gives developers a clearer understanding of the system structure, but also makes it easier for users to remember and identify resources, because the URL is simple and meaningful. According to the previous design pattern, many URLs are followed
Is a bunch of parameters, which is inconvenient for users.

Since rest is easy to use, can all web applications adopt this architecture? The answer is no. We know that, until now, the Model-View-controller mode is still the most common mode for web development. Most companies and developers adopt this architecture to develop Web applications, and the way of thinking also stays here. The MVC mode consists of data, views, and controllers. The controller is triggered by an event to change the model and view. With the addition of open-source frameworks such as webwork and struts, the MVC development model has become quite mature, and its idea is driven by action. From the developer's point of view, it is risky to accept a new architecture. There are too many uncertainties. And rest is new
The way of thinking is to abstract all user needs into resources, which is difficult to achieve in actual development, because not all user needs can be abstracted as resources, this means that not the entire system structure can be expressed through rest. Therefore, in development, we need to make a choice in rest and MVC Based on the above two points. We think it is better to mix rest and MVC, because it is suitable for most web application development, developers only need to adopt the rest development mode for user needs that can be easily abstracted as resources, and adopt MVC development for other needs. Here we need to mention the ROR (Ruby on Rails) framework, which is an increasingly popular web development framework based on the ruby language. It greatly improves the web development speed. More importantly, the ROR (from version 1.2) Box
Architecture is the first web development framework that introduces rest as the core idea. It provides the best support for rest and is also the most successful web development framework for applying rest today. In fact, the rest Implementation of ROR is a mix of rest and MVC. developers can use the ROR framework to build Web applications faster and better.

For developers, rest not only contributes to web development, but also learns how to systematically apply software engineering principles to the design and evaluation of a real software.