idempotence

Idempotent Methods are defined as Idempotent Methods at the bottom of page 50 of rFC2616 (Hypertext Transfer Protocol — HTTP/1.1) :

Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

Executing the same request multiple times has the same side effects as executing it once.

The following paragraph gives the idempotent method:

The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.

As you can see, the GET, HEAD, PUT, DELETE, OPTIONS, and TRACE methods are idempotent.

The PUT and PATCH

According to Convention, the PUT method is used to update data, and the PATCH method is also used to update data. Why is the PUT method idempotent and the PATCH method not idempotent? We continue with the document (page 54) :

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.

The PUT method stores the entities contained in the Request under the provided request-URI. If the URI refers to an existing resource, the entity in the request should be treated as a modified version of the entity stored on the original server. If the request-URI does not point to an existing resource, and the URI can be defined as a new resource by the user agent sending the Request, the original server can use the URI to create the resource.

PUT is used for updating an entire entity, not just a few attributes of the entity that need to be modified. When a URI points to an existing resource, all the server has to do is find and replace it.

Next, PATCH (PATCH method was not described in the original document, and was later found in another RFC – RFC5789) :

The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI. The set of changes is represented in a format called a “patch document” identified by a media type. If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc.

The PATCH method requests that a set of resources describing the changes in the Request entity be applied to the Request-URI flag. This set of changes is represented in a format called a “patch document” (flagged by media type). If the Request-URI does not point to an existing resource, the server may create a new resource based on the type of the patch document (whether empty resources can be logically modified), permissions, and so on.

So you can see that the entities in the PATCH request are a set of changes to be applied to the entities, rather than entities to replace old resources as in the PUT request, but this does not solve the problem of why the PATCH method is not idempotent. Take your time and read on. Here is the difference between PUT and PATCH:

The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.

The difference between PUT and PATCH requests is reflected in the way the server processes the closed entity to modify the request-URI flag resource. In a PUT request, the closed entity is considered to be a modified version of the resource stored on the source server, and the client is requesting a replacement of the stored version. For PATCH requests, the closed entity contains a set of instructions describing how the resource currently reserved on the source server should be modified to produce a new version. The PATCH method affects resources marked by request-URI, and it may have side effects on other resources as well; That is, by using PATCH, new resources can be created, or existing resources can be modified.

That’s the answer. It can be understood that the entity in the PATCH request stores the instruction to modify the resource, which instructs the server to modify the resource, so it is not idempotent. If you want to change B to 3, then the PUT request directly sends the whole new object with the changed B attribute to the server to find and replace. The PATCH request contains the instruction in the entity — to increase the value of B attribute in object A by 2. If the request is executed for many times, the B attribute may not be 3. However, no matter how many times the PUT request is executed, the B attribute will always be 3. The PATCH method is not idempotent.

The PUT and POST

When I read posts about requests, I will occasionally see arguments that use PUT to add resources and POST to modify resources, or that the two methods are not so different that there is no need for such a clear division of labor. As mentioned earlier, a resource can be created when the URI of the PUT method does not exist. So how does that work? Well, I’ve written it all over here and I’m going to continue with the documentation for the POST method:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

  • Annotation of existing resources;
  • Posting a message to a bulletin board, newsgroup, mailing list or similar group of articles;
  • Providing a block of data, such as the result of submitting a form, to a data-handling process;
  • Extending a database through an append operation.

The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.

The POST method is used by the requesting source server to accept the entity in the Request as a new child of the resource identified by the Request-URI. The POST method is designed to allow a unified approach to cover the following functionality:

  • Notes on existing resources;
  • Post messages on bulletin boards, newsgroups, mailing lists, or similar article groups;
  • Provide data blocks, such as the result of submitting a form, data processing process;
  • Extend the database by appending operations.

The actual function performed by the POST method is determined by the server and usually depends on the Request-URI. A published entity is subordinate to the URI in the same way that a file is subordinate to the directory that contains it, a news article is subordinate to the newsgroup that publishes it, or a record is subordinate to a database.

Add black the first sentence is not very familiar, RESTful API to achieve the front and back end interaction interface friends see here should be clear. This is why POST/API /articles are recommended for creating articles rather than updating articles in RESTful contexts. In addition, POST requests are not idempotent, because if they are used as resource updates, they will create multiple identical resources, which is an undesirable side effect of the update operation, so instead use POST to add resources and PUT to update resources.

Of course, these are conversions, not standards, and if you just like to use PUT to create resources and POST to modify resources, I’m sorry you took so long to read this article, There are still a lot of people using just GET and POST to do everything at 😄😄.