Aamir

Aug 27, 2022

Advanced HTTP Methods: Difference Between PUT and PATCH Request

It seems that both PUT and PATCH are modifying the data in the resource. Is that all?

Let's see the difference:-

1. Safe and Idempotent HTTP Methods

Safe Methods

In the context of REST APIs, Safe methods are HTTP methods that do not modify resources. For example, using GET or HEAD on a Request URI should never change the resource. Safe methods are methods that can be cached and prefetched without any effect on the resource.

In practice, it is often not possible to implement safe methods in a way they do not alter any resource. For example, a GET request might create a log or update statistic values, or trigger a cache refresh on the server.

It is not possible to ensure that the server does not generate side effects as a result of performing a GET request. The important distinction here is that the API consumer did not request the side effects, so therefore the consumer cannot be held accountable for them.

The request URI is the uniform resource identifier of the resource to which the request applies.

Idempotent Methods

If one or more invoking of an HTTP method have the same intended effect on the resource, this method is considered idempotent. It should not matter if the method has been called only once or three times over. The result on the resource should always be the same.

Idempotency essentially means that the result of a successfully performed request is independent of how many times it has been executed.

NOTE: When you send multiple DELETE requests, the first request deletes the resource, and the response is 200 (OK) or 204 (No Content). The next request returns 404 (Not Found). The response is different from the first request, but there is no change of state for any resource on the server side since the original resource has already been deleted. Therefore, DELETE is idempotent.

2. PUT Request

The PUT method modifies an existing resource entirely or creates a new resource. How does it do that?

--- The API consumer sends the resource ID

--- If the resource exists, the entire resource is replaced with the entire entity

--- If the resource doesn’t exist, a new resource is created

For example, when you want to change the first name of a user in a database, you need to send the entire entity when making a PUT request.

PUT /users/{user-id}
{“first": "John", "last": "Wick”}

To make a PUT request, you need to send all parameters, not just the name; the first and the last name for this example.

A successful PUT request returns an HTTP Status Code of 200 (OK) or an HTTP Status Code of 204 (No Content)if it updates successfully, and If the intended resource does not yet have a current representation and the PUT request creates one, the origin server must send an HTTP Status Code of 201 (Created) response to the API consumer.

3. Why is PUT Request Idempotent

Here The PUT request contained all of the parameters for this user.

When using the PUT request, it is assumed that you are sending the complete entity and that the complete entity replaces any existing resource at Request URI. PUT request handles it by replacing the entire resource.

Since the PUT requests include the entire entity, if you issue the same request repeatedly, it should always have the same outcome (the data you sent is now the entire data of the resource).

If you send a PUT request 5 times, the very first request will update the resource; the other 4 requests will just overwrite the same resource state again and again — effectively not changing anything.

Therefore the PUT request is idempotent.

If you have any questions, please let me know in the comments.

4. PATCH Request

The PATCH method applies a partial update to an existing resource. This means that you only need to send the data that you want to update, and it won’t affect or change anything else. Therefore, if you want to update the first name in the database, you only need to send the first parameter. For the example above, this parameter is the first name.

PATCH /users/{user-id}
{“first": "John"}

--- The API consumer sends the resource ID

--- If the resource exists, the existing resource is partially updated (not all entities are required).

--- If the resource doesn’t exist, an HTTP Status Code of 404 (Not Found) is returned

A successful PATCH request returns an HTTP Status Code of 200 (OK) or an HTTP Status Code of 204 (No Content)if it updates successfully.

5. Why is PATCH Request Non-Idempotent

The PATCH method updates a small portion of a resource. For example, if you update a resource using the PUT request and do not set all the fields, you risk losing data in the fields you left blank. PATCH request fixes this as it only updates specific portions stated in the request body.

PATCH request doesn’t always guarantee the same effect, so it’s not idempotent. In other words, it could affect changes at different parts of the Request URI.

PATCH /users/{user-id}
{“first": "John"}

In the above example, just change the users’ resource’s first name field. Then make a request to the same Request URI and modify a different field of the same resource.

PATCH /users/{user-id}
{“last": "Doe"}

In the previous two examples, the first name field was modified in the first request, and the last name field was modified in the second request. As a result, two requests were made to the same resource and got different results on each.

This change to the PATCH method gives different results depending on which part of the resource you are updating. Therefore, the PATCH is not idempotent.

ADVANCED NOTE: PATCH request can be made idempotent by using the ETag and If-Modified-Since HTTP headers.

6. When To Use PUT and PATCH Requests

When an API consumer needs to replace an existing resource entirely, the consumer can use the PUT method. When the consumer wants to make a partial update, they can use the PATCH method.

For example, when updating a single field of the resource, sending the entire entity representation can be trouble and uses a lot of unnecessary bandwidth. In such cases, the usage of the PATCH method makes a lot more sense.

7. Differences Between PUT and PATCH Requests

The main difference between  PUT and  PATCH requests is that the server processes the sent entity to update the resource identified by the  Request URI. When making a  PUT request, the sent entity is seen as a modified version of the resource saved on the original server, and the API consumer requests to change it. However, the entity sent with the  PATCHr equest has a set of instructions that describe how a resource stored on the original server must be partially modified to create a new version.

Another important aspect to consider here is idempotence. The  PUT method is idempotent, the  PATCH method can be idempotent but isn’t required to be. You can choose one or the other based on where it is implemented.

Summing UP

To summarize this article, the main differences of these methods with each other are the idempotent and how they operate with the requests from API consumers

Wrap Up. Share this article and kindly bookmark this website to get the latest blog on full-stack. Till then Good bye, happy reading.

Thank you