The rest architecture style is a new development style for Web applications, and is the most successful internet hypermedia Distributed System architecture in the world today, which makes people really understand the HTTP protocol's original appearance. With the rest architecture becoming the mainstream technology, a new way of thinking about Internet Web application development has become popular.
What is rest
Rest is an abbreviation for the English representational state transfer, translated as "representational states transfer", he was by Roy Thomas Fielding in his paper "Architectural Styles and the" Design of network-based software architectures, a term presented in. Rest itself is an architectural style, not a standard, designed for distributed hypermedia systems.
A web-based architecture, in effect, is a collection of specifications that collectively form the Web schema. such as the HTTP protocol, such as the client server model, these are specifications. Whenever we add new specifications based on the original specification, a new architecture is formed. And rest is such a structure, he combines a series of specifications, and formed a new web-based architecture style.
Traditional Web applications are mostly B/s architecture, which includes some of the following specifications.
Client-Server
This specification improves the portability of the user interface across multiple platforms and improves the scalability of the system by simplifying server components. The key is that by separating the two concerns of user interface and data storage, it is possible for different user terminals to enjoy the same data.
Non-state sex
Statelessness is another layer of specification added on the basis of client-server constraints. He requires that communication be inherently stateless, that every request from the client to the server must contain all the information necessary to understand the request. This specification improves the visibility of the system (stateless so that the client and server do not have to keep the details of each other, the server only needs to process the current request, without having to know all the request history), reliability (stateless reduces the amount of tasks that the server recovers from local errors), Scalability (statelessness makes it easy for the server to release resources because the server side does not have to save state in multiple request). At the same time, the disadvantage of this specification is also obvious, because the state data cannot be saved in the shared context on the server, thus increasing the cost of sending duplicate data in a series of request, seriously reducing the efficiency.
Cache
To improve the inefficiency of the network caused by statelessness, we have added cache constraints. Caching constraints allow the data in a response to be implicitly or explicitly tagged, giving the client the ability to cache response data so that it can share cached data for future request, partially or completely eliminating part of the interaction, increasing the efficiency of the network. However, for the client to cache the information, it also increases the likelihood of inconsistent client and server data, thereby reducing the reliability.
The advantage of B/s architecture is that it is easy to deploy, but not ideal in terms of user experience. To improve this situation, we introduced rest.
Rest adds three new specifications to the original architecture: Unified interface, tiered system, and on-demand code.
Unified interface
The core feature of the rest architecture style is the emphasis on having a unified interface between components, which is manifested in the rest world where everything on the network is abstracted as resources, and rest is manipulating 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's interactivity and reusability. And rest interfaces are designed to efficiently transfer large-grained hypermedia data, which is often optimized for web-based scenarios, resulting in a rest interface that is not optimal for other architectures.
Tiered Systems
The addition of layered system rules improves the independence of various levels, sets boundaries for the complexity of the entire system, and encapsulates the legacy services to protect the new servers from Legacy clients, which also improves the scalability of the system.
On-Demand Code
Rest allows you to extend the functionality of the client. For example, you can extend client functionality by downloading and executing code in the form of applets or scripts. However, this improves the scalability of the system while reducing visibility. So it's just an optional constraint for rest.
Design Guidelines for rest
The rest architecture is designed for Web applications to reduce the complexity of development and to improve the scalability of the system. Rest presents the following design guidelines:
All things on the network are abstracted as resources (resource);
Each resource corresponds to a unique resource identifier (resource identifier);
Operation of the resource via a common connector interface (generic connector interface);
Various operations on resources do not alter resource identifiers;
All operations are stateless (stateless).
The resources in rest refer not to the data, but to the combination of data and representations, such as "10 members with the latest access" and "the most active 10 for members" may overlap or be identical on the data, and because of their different forms of expression, they are classified as different resources. This is why the full name of rest is the reason for representational state transfer. The resource identifier is the URI (Uniform Resource Identifier), whether it's a picture, word or video file, or even just a virtual service, whether you're in XML format, TXT file format, or other file format, all through The URI uniquely identifies the resource.
Rest is based on the HTTP protocol, and any manipulation of the resource is done through the HTTP protocol. In the past, most of the Web development uses the Get and post methods in the HTTP protocol, which is rarely used for other methods, which is actually caused by a partial understanding of the HTTP protocol. HTTP is not just a simple protocol to carry data, but a rich network of software protocols. He is not only able to locate the Internet resources, but also to tell us how to operate the resource. HTTP restricts the operation of a resource to 4 methods: GET, Post,put, and delete, which is the implementation of the resource crud operation. Since the resource and URI are one by one corresponding, the URI is unchanged when performing these operations, which is very different from the previous web development. Because of this, the web development is greatly simplified, and the URI can be designed to reflect the structure of the resource more intuitively, and the design of this URI is called the restful URI. The developer introduced a new way of thinking: Designing a system structure with a URL. Of course, this design is not suitable for some specific situations, that is to say, not all URIs can be restful.
REST can improve the scalability of the system because it requires all operations to be stateless. Because there is no context constraint, it is simpler to do the distribution and clustering, and it allows the system to make more efficient use of the buffer pool. And because the server side does not need to record the client's series of accesses, also reduces the server side performance.
Using the rest architecture
For developers, the concern is how to use the rest architecture, and here's a brief discussion. Rest is not just a new architecture, it's a new way of thinking in the Web development process: Designing the system structure through URLs. In rest, all URLs correspond to resources, so long as the URL is well designed, the system structure is good. This is similar to TDD (Test driven development), where he designs the interface of the system through test cases, each of which represents the needs of a series of users. Developers do not need to write functionality from the start, but simply show the functionality that needs to be implemented in the form of test cases. This is similar to designing a system structure through URLs in rest, we only need to design a reasonable URL according to the requirements, these URLs do not have to link to the specified page or do some behavior, as long as they can visually display the user interface of the system. 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, and the job developers need to do is to abstract user requirements into resources and how to abstract them accurately. Because the more accurate the abstraction of resources is, the better it is for rest applications. This differs greatly from the action-based thinking in the traditional MVC development model. Well-designed URLs, not only for developers to more clearly understand the structure of the system, it is easy for users to remember and identify resources, because the URL is simple enough and meaningful. According to the previous design pattern, many URLs are followed by a bunch of parameters, which is inconvenient for the user.
Since rest is so useful, is it possible for all Web applications to adopt this architecture? The answer is in the negative. We know that until now, the MVC (Model-view-controller) pattern is still the most common pattern of web development, and the vast majority of companies and developers have adopted this architecture to develop Web applications, and their way of thinking remains. The MVC pattern consists of data, views, and controls that trigger a controller through events to change the model and view. With the addition of open-source frameworks such as webwork,struts, the MVC development model is quite mature and its ideas are driven by action. From a developer's point of view, taking a new architecture rashly can be risky, with too many uncertainties. And the new way of thinking in rest is to abstract all user requirements into resources, which is difficult to do in real-world development, because not all user requirements can be abstracted as resources, which means that not the entire system structure can be represented by rest. So in development, we need to make choices in rest and MVC based on the 2 points above. We think the better approach is to mix rest and MVC, because this is suitable for the vast majority of web application development, and developers only need to take the rest of the development model for users who are more likely to be abstracted into resources, and take MVC development for other requirements. What you need to mention here is the Ror (Ruby on Rails) framework, an increasingly popular web development framework based on the Ruby language, which greatly improves the speed of web development. More importantly, the ROR (from version 1.2) framework is the first Web development framework to introduce rest as a core idea, providing the best support for rest and the Web development framework for today's most successful application rest. In fact, Ror's rest implementation is a mix of rest and MVC, and developers use the ROR framework to build Web applications faster and better.
For developers, rest not only contributes to web development, but also allows us to learn how to apply software engineering principles systematically to the design and evaluation of a real software.
What is a rest architecture
