What’s the Difference between PUT vs PATCH?

PUT vs PATCH

When learning web development and HTTP specification, it is not unlikely to find yourself getting confused about the type of verb to use, and when to use it. With most applications on the internet being CRUD (create, read/retrieve, updates, delete), developers must learn how to match HTTP verbs to these actions. Typically, the verbs and actions are matched as follows:

• POST – Create
• GET – Read/Retrieve
• PUT/PATCH – Update
• DELETE – Delete

From this mapping, it is not surprising that most people think that PUT and PATCH are allies that do the same thing. However, the reality is far more complex, especially when it comes to overlapping functionality and other complications. Actually, PUT and PATCH might be doing the same thing of updating a resource at a location, but they do it differently. Therefore, to understand more about these verbs, let’s dive deep into HTTP specification and identify the subtle differences between the two.

Browse the Best Free APIs List

What is PUT?

PUT is a method of modifying resource where the client sends data that updates the entire resource. It is used to set an entity’s information completely. PUT is similar to POST in that it can create resources, but it does so when there is a defined URI. PUT overwrites the entire entity if it already exists, and creates a new resource if it doesn’t exist.

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

{“first": "John", "last": "Stone”}

To make a PUT request, you need to send the two parameters; the first and the last name.

What is PATCH?

Unlike PUT, PATCH applies a partial update to the resource.

This means that you are only required to send the data that you want to update, and it won’t affect or change anything else. So if you want to update the first name on a database, you will only be required to send the first parameter; the first name.

Differentiating PUT and PATCH Using an Analogy of Land

Imagine we have empty a piece of land where we have the option to erect multiple houses. The land is divided into plots and houses will be built on each plot as designated by numbers. All we need it to do is to determine which house will be built where.
When we translate the above information to REST, we will have the following:
https://domain.com/house

PUT

Let say plot 1 has a house that has been equipped with all the amenities. Making a PUT request can lead to a number of outcomes. However, to stick to the topic, let’s consider the following request: https://domain.com/house/1 using this payload:

{
 "front_patio": true,
 "back_patio": true,
 "windows": 12,
 "doors": 4,
 "Balcony": false
}

Now that we have a house on plot 1, what will happen is that every property on the house will be replaced by the data in the payload. So, if our payload only had the following information:

{
 "doors": 5
}

We will have a house that has doors property and nothing else since a PUT request overwrites everything.

What if we issue a PUT request on a resource that doesn’t exist. In this case let’s say on plot 3: https://domain.com/house/3. In this case, a new resource will be created. But it is crucial to note that, it is imperative to define the entire resource when making PUT requests or else it could yield undesired results.

PATCH

PATCH is used when you want to apply a partial update to the resource. Let’s assume the house on plot 1 has the following features:

{
 "front_patio": true,
 "back_patio": true,
 "windows": 12,
 "doors": 4,
 "Balcony": false
}

And we want to make the following update:

{
 "doors": 5
}

The result will be as follows:

{
"front_patio": true,
"back_patio": true,
"windows": 12,
"doors": 5,
"Balcony": false
}

Additionally, we can also add a new feature that didn’t exist in the resource. For example, a garage and the result will be:

{
"front_patio": true,
 "back_patio": true,
 "windows": 12,
 "doors": 5,
 "Balcony": false,
 “garage”: true
}

However, you should note that calling HTTP PATCH on a resource that doesn’t exist is bound to fail and no resource will be created.

A Summary of Differences/Similarities between PUT and PATCH

From the discussion above, we can clearly outline the similarities/ differences between these two methods.

Similarities between PUT and PATCH

The only similarity between the two is that they can both be used to update resources in a given location.

Differences between PUT and PATCH

The main difference between PUT and PATCH requests is witnessed in the way the server processes the enclosed entity to update the resource identified by the Request-URI. When making a PUT request, the enclosed entity is viewed as the modified version of the resource saved on the original server, and the client is requesting to replace it. However, with PATCH, the enclosed entity boasts a set of instructions that describe how a resource stored on the original server should be partially modified to create a new version.

The second difference is when it comes to idempotency. HTTP PUT is said to be idempotent since it always yields the same results every after making several requests. On the other hand, HTTP PATCH is basically said to be non-idempotent. However, it can be made to be idempotent based on where it is implemented.

Final Verdict

Now that you have a clear outlook of the similarities/differences between PUT and PATCH, you will probably make the best choice when designing a RESTful API or a new web application. Understanding these subtle differences will help improve your experience when integrating and creating cooperative apps.

Related Reading

• How to use an API
• How to build an API
• API Glossary

Where to get Free APIs?

Get access to these top APIs for free only on RapidAPI.

Browse the Best Free APIs List