Preface: I would like to write this article in memory of once mistakenly thought that REST style simply means POST/DELETE/PUT/GET corresponding to add, DELETE, change and check, URL does not PUT add/ DELETE/ update, oh young people in that young person of me.

What are REST and RESTful?

REST — REpresentational State Transfer, which translates directly into REpresentational State Transfer. It is an architectural design style that describes a form of interaction between the client and the server. It is often summarized as “URL defines resources and HTTP verbs describe operations”. Applications or designs that meet this design style are considered RESTful architectural styles.

RESTful is a resource-oriented Architecture (ROA). In ROA, the objects being processed, any objects that need to be referenced, are resources. Resources, on the other hand, are represented by a specific URI.

In REST, the client communicates directly with the server, transmitting representations of resources. There are three important terms involved: “resource”, “representation” and “state transition”.

  • Resources refer to the data that the server can provide. This data may be physical data or media information, such as images, PDFS, text, and other data required by various clients.
  • Representation refers to some form of representation of a resource. This representation does not have to be all of the information, it can only be part of the information concerned, and a message can also correspond to multiple statements. For example, for a student in school, we can use his name and student number for positioning, and can also use his location information such as which classroom and which row for positioning.
  • State transitions are a series of operations on data. A resource may undergo a series of creation, deletion, modification, or query processes as its requirements change. The client uses THE REST API to specify the request method, resource path, and resource expression to add, delete, modify, and query the status of the resource, thus causing the change of the resource. This is called state transfer.

In summary, the client performs a series of operations on the server’s resources through the REST API, resulting in resource state transfer. And this shift is embodied in the statement, and that’s where the “declarative state shift” comes from.

Why use RESTful architecture?

Compared to the usual interface design approach, the most important advantage of a Restful architecture is that it shifts the primary consideration of system design from operations to resources.

For example, when we need to design a library management system, what do we think of?

  • Add books:/book/add? id=123
  • Delete books:/book/delete? id=123
  • Modify book information:/book/update
  • Find a particular book:/book/get? id=123
  • Find a book by an author:/book/getByAuthor? author=1&page=1

Write up very smoothly, look very logical, is the need for any interface to translate this operation into the corresponding word! Considering only from the application level, this is not too big a problem, after all, for some small and medium-sized projects, the more important place is the practicality of the system. What would these interfaces look like if they were RESTful?

  • Add books:POST /books/123
  • Delete books:DELETE /books/123
  • Modify book information:PUT /books/123
  • Find a particular book:GET /books/123
  • Find a book by an author:GET /author/1/book? page=1

At first glance, add, DELETE, alter, and view may seem like the equivalent of POST/DELETE/PUT/GET, but it shows two completely different design approaches. Unlike the action-oriented API design style, REST is resource-oriented. Resources are exposed through URIs, which are only responsible for providing resources to callers in a reasonable way, with HTTP verbs to do so.

The most obvious is GET /author/1/book? Page =1 compared to /book/getByAuthor? author=1&page=1 :

Author is a kind of resource, so its ID is directly placed in the URI when searching, that is, by accessing this URI, we can directly obtain all the information about the author whose ID is 1. Page is a resource condition that filters the resource, so we put it in the request parameters.

So what’s the advantage of being resource-oriented? This can be summarized in the following aspects:

  • It can make urls very readable and self-descriptive
  • Loose coupling between resource description and view is achieved
  • OpenAPI can be provided to facilitate integration of third-party systems, thereby improving interoperability
  • If stateless service interfaces are provided, horizontal scalability of applications can be improved

What are the six constraints of REST?

Client-server constraints

This constraint is based on the principle of separation of concerns. By separating the two concerns of user interface and data storage, it increases the possibility of user interface cross-platform and improves system scalability by simplifying server components. This separation allows components to be modified and extended independently to support the networking needs of a large number of organizations.

Stateless constraint

Stateless constraint means that there is no dependency between two requests and each request contains complete state information.

For example, if we want to query the salary, first need to log in the system (the first request), and then input the query password (the second request), the current two requests are passed, you can query the salary, when the failure, reported no authentication error; The return result of the query interface is associated with the status of the previous two requests, so it is a stateful service.

For stateless services, the interface to query wages can be invoked directly. The request sent by the client (usually in the Header) contains information related to authentication. If the server passes the authentication, it queries the salary. If the server fails to pass the authentication, an error is reported. The request does not depend on any prior request and is called stateless.

REST uses stateless constraints to ensure request independence and simplicity, reducing much of the cost of maintaining state across requests, but also resulting in more redundant information that may need to be transferred with each request.

Cacheable constraint

This constraint can be used to improve the efficiency of the network. Cache constraints require that the data in the response of one request be marked either implicitly or explicitly as cacheable or non-cacheable, and one side of the client uses the stale response data to send other requests. A good caching strategy can effectively reduce the interaction between the client and the server, thus further improving the scalability and performance of the system.

Hierarchical system constraint

Layered systems require that the architecture be divided into several layers and the boundaries of each layer be defined to reduce the complexity of the design of each layer. At the same time, layers can abstract the heterogeneity of the bottom layer, provide unified interfaces for the upper layer, and simplify the logic of the upper layer.

On-demand code constraints (optional)

On-demand code means that, in some cases, if the client does not know how to handle the resource, it can be executed by asking the server for the appropriate handling code. This simplifies client development and allows functional code to be downloaded after deployment to improve system scalability. However, it is an optional constraint of REST because you are transferring code, which reduces visibility.

Unified Interface constraints

Unifying interface constraints is fundamental to designing any REST service. It simplifies and decouples the architecture so that each part can be modified independently. This unified interface contains the following specific constraints:

1. Identification of resources:

The various resources are identified in the request, and the resources themselves indicate the format they want to be returned to the client. For example, a server can send data in HTML, XML, or JSON format from its database, even if these are not internal server data formats.

2. Manipulate resources by representation

When a client holds a representation of a resource, including any associated metadata, it has enough information to modify or delete the resource.

3. Self-describing messages

Each message contains enough information to describe how to process the message itself, such that a network media type is itself a parser (such as a MIME type) capable of running that media.

4. Hypermedia as the engine of application state (HATEOAS)

The most important feature of REST services that meet the HATEOAS constraint is that the representation provided by the server to the client contains dynamic link information through which the client can discover the action that triggers the state transition.

Write in the last

I looked at the concept again and realized it was all about me, QAQ.

Although there are so many constraints, the important thing is awareness. After all, some interfaces would be very inconvenient to design if they were completely RESTful, such as login, which is an operation in itself rather than a resource requirement. Therefore, if you want to design a RESTful architecture style system, you can adhere to the resource-oriented thought, without increasing the difficulty of system maintenance, some of the interfaces that are not convenient for REST protocol can be flexible, thus allowing some “less REST” interface to exist.

The above. OvO