I am using a PUT request in my Rails application. Now, a new HTTP verb, PATCH has been implemented by browsers. So, I want to know what the main difference between PATCH and PUT requests are, and when we should use one or the other.


HTTP verbs are probably one of the most cryptic things about the HTTP protocol. They exist, and there are many of them, but why do they exist?

Rails seems to want to support many verbs and add some verbs that aren't supported by web browsers natively.

Here's an exhaustive list of http verbs: http://annevankesteren.nl/2007/10/http-methods

There the HTTP patch from the official RFC: https://datatracker.ietf.org/doc/rfc5789/?include_text=1



As far as I know, the PATCH verb is not used as it is in rails applications... As I understand this, the RFC patch verb should be used to send patch instructions like when you do a diff between two files. Instead of sending the whole entity again, you send a patch that could be much smaller than resending the whole entity.

Imagine you want to edit a huge file. You edit 3 lines. Instead of sending the file back, you just have to send the diff. On the plus side, sending a patch request could be used to merge files asynchronously. A version control system could potentially use the PATCH verb to update code remotely.

One other possible use case is somewhat related to NoSQL databases, it is possible to store documents. Let say we use a JSON structure to send back and forth data from the server to the client. If we wanted to delete a field, we could use a syntax similar to the one in mongodb for $unset. Actually, the method used in mongodb to update documents could be probably used to handle json patches.

Taking this example:

   { sku: "unknown" },

We could have something like this:

PATCH /products?sku=unknown
{ "$unset": { "quantity": "", "instock": "" } }

Last, but not least, people can say whatever they want about HTTP verbs. There is only one truth, and the truth is in the RFCs.

  • 1
    It is important to note that RFC 5789 is still in proposal phase and has not been officially accepted and is currently flagged as 'irrata exist'. This 'best practice' is highly debated and technically PATCH is not yet part of the HTTP standard. The only truth here is that since the RFC is unaccepted, you should not be doing it. – fishpen0 Oct 5 '15 at 21:32
  • 3
    Even if it's still in proposal, it doesn't mean it shouldn't be used. If it was the case, we wouldn't be able to use websockets and many other rfcs that are still in proposal... Implementing the proposal is 100 times better than implementing something completely custom that nobody else implement. – Loïc Faure-Lacroix Oct 6 '15 at 5:20
  • BS. It's not "in proposal", and it's part of the HTTP standard (the standard, RFC 7231 delegates to an IANA registry for methods, and PATCH is listed there). – Julian Reschke Nov 10 '16 at 21:46
  • @JulianReschke if you read the second line of this RFC, you'll see that it's still marked as PROPOSED STANDARD. So no, the patch method is still in proposal. The rfc is here btw. tools.ietf.org/html/rfc5789 and the rfc7231 is also PROPOSED STANDARD. If you look at the RFC821 for example, it's marked as INTERNET STANDARD – Loïc Faure-Lacroix Nov 10 '16 at 21:56
  • 1
    @JulianReschke en.wikipedia.org/wiki/Internet_Standard#Proposed_Standard ... It's not my word. A proposed standard doesn't mean you can't implement it fine as I explained above. It doesn't mean that it's not stable enough to implement... but it is still in proposal unless it's marked as Internet Standard... I'm not sure how you're arguing on that. It's called "proposed standard" it can't mean anything else than a proposal. If you want to argue that a proposed standard can be used. It's exactly what I wrote. – Loïc Faure-Lacroix Nov 11 '16 at 13:53

I spent couple of hours with google and found the answer here

PUT => If user can update all or just a portion of the record, use PUT (user controls what gets updated)

PUT /users/123/email

PATCH => If user can only update a partial record, say just an email address (application controls what can be updated), use PATCH.

PATCH /users/123
[description of changes]

Why Patch

PUT method need more bandwidth or handle full resources instead on partial. So PATCH was introduced to reduce the bandwidth.

Explanation about PATCH


PATCH is a method which 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.

PATCH /users/123
  { "op": "replace", "path": "/email", "value": "new.email@example.org" }

Here more information about put and patch

  • 7
    Why is this PATCH not safe? – Bishisht Bhatta Nov 17 '16 at 15:56
  • 2
    PATCH among POST, PUT etc. is not "safe", because it modifies your data (has side effects). Compared to GET, OPTIONS etc. (safe methods) where you can call the endpoints multiple times without any side effects. – emix Jul 13 '18 at 6:57
  • 2
    PATCH was NOT introduced to solely save bandwith. As RFC 5789 states: > "A new method is necessary to improve interoperability and prevent errors." In multi parallel environment having only PUTs that include the rest of the payload would increase the risk of modification of other attributes of the resource. PATCH solves such problem. – Tomasz Nazar Dec 27 '18 at 15:13

If I want to update my first name, then I send a put request:

{ "first": "Nazmul", "last": "hasan" } 

But here is a problem with using put request: When I want to send put request I have to send all two parameters that is first and last (whereas I only need to update first) so it is mandatory to send them all again with put request.

patch request, on the other hand, says: only specify the data which you need to update and it won't be affecting or changing other data.
So no need to send all values again. Do I only need to change first name? Well, It only suffices to specify first in patch request.


Here are the difference between POST, PUT and PATCH methods of a HTTP protocol.


A HTTP.POST method always creates a new resource on the server. Its a non-idempotent request i.e. if user hits same requests 2 times it would create another new resource if there is no constraint.

http post method is like a INSERT query in SQL which always creates a new record in database.

Example: Use POST method to save new user, order etc where backend server decides the resource id for new resource.


In HTTP.PUT method the resource is first identified from the URL and if it exists then it is updated otherwise a new resource is created. When the target resource exists it overwrites that resource with a complete new body. That is HTTP.PUT method is used to CREATE or UPDATE a resource.

http put method is like a MERGE query in SQL which inserts or updates a record depending upon whether the given record exists.

PUT request is idempotent i.e. hitting the same requests twice would update the existing recording (No new record created). In PUT method the resource id is decided by the client and provided in the request url.

Example: Use PUT method to update existing user or order.


A HTTP.PATCH method is used for partial modifications to a resource i.e. delta updates.

http patch method is like a UPDATE query in SQL which sets or updates selected columns only and not the whole row.

Example: You could use PATCH method to update order status.

PATCH /api/users/40450236/order/10234557

Request Body: {status: 'Delivered'}


There are limitations in PUT over PATCH while making updates. Using PUT requires us to specify all attributes even if we want to change only one attribute. But if we use the PATCH method we can update only the fields we need and there is no need to mention all the fields. PATCH does not allow us to modify a value in an array, or remove an attribute or array entry.


According to HTTP terms, The PUT request is just-like a database update statement. PUT - is used for modifying existing resource (Previously POSTED). On the other hand the PATCH request is used to update some portion of existing resource.

For Example:

Customer Details:

// This is just a example.

firstName = "James";
lastName = "Anderson";
email = "email@domain.com";
phoneNumber = "+92 1234567890";

When we want to update to entire record ? we have to use Http PUT verb for that.

such as:

// Customer Details Updated.

firstName = "James++++";
lastName = "Anderson++++";
email = "email@Updated.com";
phoneNumber = "+92 0987654321";

On the other hand if we want to update only the portion of the record not the entire record then go for Http PATCH verb. such as:

   // Only Customer firstName and lastName is Updated.

    firstName = "Updated FirstName";
    lastName = "Updated LastName";


When using PUT request we have to send all parameter such as firstName, lastName, email, phoneNumber Where as In patch request only send the parameters which one we want to update and it won't effecting or changing other data.

For more details please visit : https://fullstack-developer.academy/restful-api-design-post-vs-put-vs-patch/


PUT and PATCH methods are similar in nature, but there is a key difference.

PUT - in PUT request, the enclosed entity would be considered as the modified version of a resource which residing on server and it would be replaced by this modified entity.

PATCH - in PATCH request, enclosed entity contains the set of instructions that how the entity which residing on server, would be modified to produce a newer version.


Put and Patch method are similar . But in rails it has different metod If we want to update/replace whole record then we have to use Put method. If we want to update particular record use Patch method.


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.

Your Answer

