REST – HTTP POST vs. HTTP PUT

When to Use HTTP Post vs HTTP PUT vs HTTP Patch

There seems to often be some confusion as to when to use the HTTP POST versus the HTTP PUT method for REST services. Most developers will try to associate CRUD operations directly to HTTP methods. I will argue that this is not correct, and one cannot simply associate the CRUD concepts to the HTTP methods. That is:

• Create => HTTP PUT
• Retrieve => HTTP GET
• Update => HTTP POST
• Delete => HTTP DELETE

It is true that the R(etrieve) and D(elete) of the CRUD operations can be mapped directly to the HTTP methods GET and DELETE respectively. However, the confusion lies in the C(reate) and U(pdate) operations. In some cases, one can use the PUT for a create while in other cases a POST will be required. The ambiguity lies in the definition of an HTTP PUT method versus an HTTP POST method.

Differences between POST vs. PUT

According to the HTTP 1.1 specifications the GET, HEAD, DELETE, and PUT methods must be idempotent, and the POST method is not idempotent. That is to say that an operation is idempotent if it can be performed on a resource once or many times and always return the same state of that resource. Whereas a non-idempotent operation can return a modified state of the resource from one request to another. Hence, in a non-idempotent operation, there is no guarantee that one will receive the same state of a resource.

Based on the above idempotent definition, my take on using the HTTP PUT method versus using the HTTP POST method for REST services is:

Use the HTTP PUT method when:

• The client 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 original server.
• The server will provide some information concerning the newly created resource. For example, take a logging system. A new entry in the log will most likely have a
  numbering scheme which is determined on the server side. Upon creating a new log entry, the new sequence number will be determined by the server and not by the client.
• On a modification of a resource, the server will provide such information as a resource state or an update date. Again, in this case not all information was provided by the client and the resource will be changing from one modification request to the next. Hence a non-idempotent operation.
• HTTP PUT can be used for both creating and/or updating records.

These operations can be performed multiple times with the same results. That is the resource will not be changed by requesting the operation more than once. Hence, a true idempotent operation.

Use the HTTP POST method when:

• The client includes all aspects of the resource including the unique identifier to uniquely identify the resource. Example: creating a new employee.
• The client requests 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.
• The client provides all the information for a resource to be able to modify that resource. This implies that the server side does not update any aspect of the resource (such as an update date).
• Creating new records.

Use the HTTP PATCH method when: 

• When updating only a single field in an existing record
• Patch is more granular, we can send a single field we need to update 
• Lower overhead of sending the whole resource
• Not usded by FileCatalyst nor GoAnywhere

Conclusion: HTTP POST vs. PUT

Do not directly correlate and map CRUD operations to HTTP methods for REST services. The use of an HTTP PUT method versus an HTTP POST method should be based
on the idempotent aspect of that operation. That is, if the operation is idempotent, then use the HTTP POST method. If the operation is non- idempotent, then use the HTTP PUT method.