The Dev Room

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.

Browse APIs

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.

Browse APIs

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.

Browse APIs

Related Reading

Where to get Free APIs?

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

Browse the Best Free APIs List

3.4/5 - (34 votes)

View Comments

  • Are you really sure "that calling HTTP PATCH on a resource that doesn’t exist is bound to fail and no resource will be created"? I tried a sample in my local with SpringBoot. And I can create a resource if it doesn't exist while using Patch Request

  • Hi,
    when i try to practice based on this article using Laravel 7 as the REST API , i cant found the difference, the PUT and the PATCH is work in the same way. What i mean is, when i just send one resource, PUT just update one field and not override the whole resource. Can you tell me in which way that im wrong or can you tell me what programming language that do you use in this article?

  • HTTP Verbs are just conventions. It's like an agreement between developers. They don't necessarily force any use-case on your API. It's developer's responsibility to create API's based on API conventions. You might as well delete a resource with a POST. Or as a matter of fact, you can do anything with any of the HTTP verbs. One restriction is that, with GET, it's not possible to send a body in the request. Only headers.

  • What Alican said.
    The Internet Engineering Task Force have defined the HTTP verbs in several RFCs, but ultimately it's up to the developers to follow the standards and implement them in their systems. If you want to, you can create an API that deletes entities on receiving PUT requests. It's not *right*, but it's possible.

    My point here is that the PUT and PATCH verbs do not dictate how a request is processed server side - it's more of a hint to the server about how the client wants the server to handle the request. I've worked with many APIs over the recent years. Some of the APIs I've used only operate on GET for retrieval, POST for creation and updates (both full updates and partial updates), and DELETE for deletion (no PUT or PATCH involved). Others have implemented GET, POST, PUT, PATCH and DELETE. It's all about how the developers built their system.

    In short, you need to read documentation for the specific API you're intending to use to figure out what verbs are expected for which operations. Developers can both use and abuse them.

Share
Published by

Recent Posts

Power Up Your Enterprise Hub: New March Release Boosts Admin Capabilities and Streamlines Integrations

We're thrilled to announce the latest update to the Rapid Enterprise API Hub (version 2024.3)!…

2 weeks ago

Unveiling User Intent: How Search Term Insights Can Empower Your Enterprise API Hub

Are you curious about what your API consumers are searching for? Is your Hub effectively…

2 weeks ago

Rapid Enterprise API Hub Levels Up Custom Branding, Monetization, and Management in February Release

The RapidAPI team is excited to announce the February 2024 update (version 2024.2) for the…

4 weeks ago

Supercharge Your Enterprise Hub with January’s Release: Search Insights, Login Flexibility, and More!

This January's release brings exciting features and improvements designed to empower you and your developers.…

3 months ago

Enhanced Functionality and Improved User Experience with the Rapid API Enterprise Hub November 2023 Release

Rapid API is committed to providing its users with the best possible experience, and the…

5 months ago

The Power of Supporting Multiple API Gateways in an API Marketplace Platform

In today's fast-paced digital world, APIs (Application Programming Interfaces) have become the backbone of modern…

6 months ago