REST note (1): understanding of URI tunnel technology and CRUD operations

Recently, I have read REST practices such as Jim Webber and some experiences. Therefore, I would like to make a brief summary of some concepts. The following is my personal understanding and understanding. If there is any deviation, I hope to correct it.

• 1. URI tunneling technology.

A method of transferring information across system boundaries through URI. It encodes the information into the URI. Such as: http://www.taobao.com/PlaceOrder? Size = {xx} & type = {xx} & color = {xx} is an effective method. Because it is easy to understand on both the Server side and the Client side. However, in general, URI tunneling is not Web-friendly. Because it does not describe how resources are operated and the metadata used when resources are operated. If a consumer uses the Get operation to operate the above URI to generate resources, it completely violates the Web architecture principles.

• 2. CRUD WebService.

Before talking about CRUD, let's talk about idempotence.
Idempotence is a mathematical concept. The results of this operation are the same no matter how many operations are performed. For example, calculate the absolute value in mathematics.

2.1 C: Create.
The Create resource is created through the http post action. POST is designed as insecure and idempotent in the HTTP protocol. Why is it insecure? Because the consumer posts information to the service, the service needs to create resources for the client. In this way, the number of server resources and the organization form may be changed. Why is it not idempotent?
According to the HTTP protocol specification, after the POST information is sent to the server, the server needs to create resources. A post creates a new resource even if the information submitted by the consumer is completely consistent.

2.2 R: Read.
Read resources. Obtained through the http get operation. Security and power. Because it acquires resources multiple times, but does not operate on the resource status, it is safe.
Some people may say that, for example, if the blog Park obtains a 48-hour reading ranking, the same information should be obtained every time according to the power, without updating the information. Yes, you are right. If the resources are the same each time, they should not be updated. The idempotence here refers to the consistency of the nature of such resources. Instead of saying that the resource statement should be the same every time.

2.3 U: Update.
The PUT Operation updates resources. It is idempotent but insecure. Idempotence is manifested in its multiple operations on resources. At the server end, according to the HTTP standard, the server should completely replace the corresponding resources uploaded by the client. This may cause changes to the server's resource status, so it is not secure.
After the PUT operation is complete, a detailed description of the 200 message or 204 no content is returned to the client. However, the latter is more efficient because there is less information. Of course, the PATCH verb is added to the latest IETF Internet standard. However, PATCH sends PATCH information to some resources, and the server updates the resources.

2.4 D: DELETE.
DELETE: deletes a resource. Like the Update operation, idempotence is not safe. Note: The DELETE here is not necessarily true if the server deletes a resource, but it indicates that a REST client no longer cares about this resource, however, these resources may be used by other clients.

• 3. Check the resource status.

In distributed system applications, multiple consumers often interact with one resource. This may cause a problem. For example, a user changes the status of a resource by performing operations on it, and the other consumer does not Get the latest status through Get. Similarly, operations on this resource will not Get the desired result.
HTTP provides a simple but powerful mechanism to solve this problem. The Request resource is corrected by using the Entity Tag and Conditional Request Header If-Match or If-None-Match. An entity tag is an opaque token that associates the server with the resource to be unique throughout the resource lifecycle. You can use the Hash algorithm to specify the ETag value.
If-Match or If-None-Match is easy to understand. If the Match is true, what should be done If the Match is not true.
Generally, If-Match: "*" indicates that the resource exists. If-None-Match: "*" indicates that the resource does not exist.
Limited space, this section is so much. Hope to help you understand REST.
The next section describes the hypermedia service and related concepts.