What's the differences between PUT and PATCH?

In this article you can find a really good explanation of PATCH request.

Thanks @HRcc

I actually read that bog post. But I couldn't wrap my head around it still. Maybe it's my 12hr work day thus far...or just lack of understanding the method. That's why I was hoping to get some [simple] real world examples.

@HRcc (or anyone else) Check out the video below. I found an example. Why is @JeffreyWay using PATCH instead of PUT?

5:10 mark it starts...

https://laracasts.com/series/laravel-5-fundamentals/episodes/13

Hi @mikebarwick,

Here you have the RFC: https://datatracker.ietf.org/doc/rfc5789/?include_text=1

The difference between the PUT and PATCH requests is reflected in the way the server processes the enclosed entity to modify the resource identified by the Request-URI. In a PUT request, the enclosed entity is considered to be a modified version of the resource stored on the origin server, and the client is requesting that the stored version be replaced. With PATCH, however, the 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. The PATCH method affects the resource identified by the Request-URI, and it also MAY have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH.

But it's not clear right?

If you see at the REST cookbook, I found a very good explanation, this is what I learn and understand: http://restcookbook.com/HTTP%20Methods/patch/

From what I understand, PATCH is used for updating partial data (a few fields) and PUT is used for updating all the data (all fields).

Example 1: you have a profile settings page and in the form you want to change only your name but not your twitter account and github account. You'll only update part of the data. For that, you will use a PATCH request.

Example 2: You have a form with location settings where you have to change all of the fields: City, Country, Zip Code, Address etc. For that, you'll use a PUT request.

• PUT - update a resource (by replacing it with a new version)*
• PATCH - update part of a resource (if available and appropriate)*

http://51elliot.blogspot.com/2014/04/rest-api-best-practices-http-and-crud.html

@mikebarwick Well, to be honest, when sending a form like that, I think (given you take conventions into consideration) it would be suitable to use PUT request instead. Usually you'll use named route something.update and it responds to both PUT and PATCH in Laravel. However since you're often submitting form with all fillable fields on the model, it's more of a PUT update.

PATCH request (the real one) on the other hand would require different logic in update method of your controller (since the request has different convention) and would make more sense for public API endpoint of your resource.

But all in all it's just a convention/recommendation - in the past I often used get requests to delete entries and those apps are still running today with no problems. You just need to make sure, that you'll provide good docs for your public API. There are not many worse things than to use nonstandard API without docs.

@mikebarwick There is pretty much no difference in simple browser app. However if you want/need to really follow the http standards, eg. in REST APIs, the difference is more than just partial/whole update.

PUT request is able to store the entity at given address:

PUT /users/123

will either replace the resource users with identifier 123 if it already exists OR store the data as a resource with identifier 123. The server must make sure that sent content is complete (ie. it is whole resource, not just part of it).

PATCH on the other hand can only update existing resource AND may affect other, related resources, but the server must make sure the changes are atomic (every resource has been updated, not just some of them). That said, you must know the URI identifying existing resource for a PATCH request, while you don't have to when sending a PUT request.

Also, PUT is considered idempotent, unlike PATCH (meaning, the resource will not change after another one/multiple PUT requests with the same content, while PATCH reult can differ).

There are also other requirements that origin server must fulfill, headers and stuff.. Read the RFCs if you want more :)

@raffles @RomainLanz @JarekTkaczyk @HRcc Thanks guys. This makes much more sense now. So to make a long [complicated] story short...

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

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

I'll stick to PUT for the majority of things until I fully wrap my head around it all. Not building an API, so as you guys suggest, might not really matter too much.

@HRcc you mention to set-up a named route that will use both PUT and PATCH. Would would that work? Back-end solves which one to use on it's own...

e.g?

Route::patch('tasks/{id}', ['as' => 'tasks.update', 'uses' => 'TaskController@update']);
Route::put('tasks/{id}', ['as' => 'tasks.update', 'uses' => 'TaskController@update']);

Just as a side note, PATCH is not yet a standard. I've encountered an issue where one customer's firewall/proxy/cache/whatever is turning our front end's PATCH into METHOD_OTHER (this is according to Bugsnag) before it reaches our API, which Laravel then cannot route.

Unless you know for certain, PUT is safer, and it might be best to put a header/flag in the request to say that a partial update. It's not ideal, but hopefully things will improve soon!

@mikebarwick Yes it works. You can view available routes after creating a resource and you'll see something similar.

I know I'm gravedigging this topic a bit, but I found this interesting (if you can get past the slightly obnoxious title) ...

http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/

For my part, I think that more often than not PUT is the correct request for most of our purposes as Laravel developers because typically we're just making simple key-value updates on a single resource. PATCH would be more for a set of instructions applying to more than one service or resource, so instead of sending 3 separate requests to update 'user', 'articles', and 'tags' respectively you could send one PATCH request to update all of them (if you have the method to support this). I guess I would say it's like when being asked to pick up a gallon of milk while you're out (simple PUT request), vs being sent out with a set of instructions on what to get and where to get them, say "get milk from the grocery store", "return shirt that didn't fit to the department store", "get car battery at auto store" etc. (PATCH request).

I think generally, like @HRcc said, it's all just convention. It's easy to get too wrapped up in the shiny new toys and forget that most of the time, simpler is better. Heck, Stripe (one of my favorite companies) has an API that only uses POST and DELETE methods. There really is something to be said for making things easy.

I'd be really interested to see why @JeffreyWay uses PATCH in the tutorial. That's what got me thinking about it more as well.

As i could understand POST/PUT are sort of INSERT/UPDATE query in SQL while PATCH could be used like SQL transactions. Am I on the right track?

@redcore, this article changed my whole idea of put and patch, ty!

Something else to consider here is the spec which relates directly to relationships and also some eloquent defaults:

PUT = replace the ENTIRE RESOURCE with the new representation provided (no mention of related resources in the spec from what i can see)

PATCH = replace parts of the source resource with the values provided AND|OR other parts of the resource are updated that you havent provided (timestamps) AND|OR updating the resource effects other resources (relationships)

From a laravel / Eloquent point of view its almost impossible to use a PUT request if following the spec as YOU dont/wont send created_at and updated_at data when trying to update the resource, which you would need to, to satisfy the spec.

Think of it this way:

$resource = Model::findOrFail($id);
$resource->fill($request->only([.....]));
$resource->save();

This MUST be a patch request as calling save will update the timestamps in the db without you providing it in the request. (asuming you use timestamps on the model.

Whereas:

DB:table('tablename')->where('id', $id)->delete();//we do this to ensure the entire dataset is replaced
DB:table('tablename')->insert($request->except('_token'));//this must also contain the id

would be a PUT request as you are replacing the entire row/resource with whats provided in the request.

Delayed response - but detailed! I'll accept and close. ;)

Hi @no12pixels,

Now that we understood the difference between PUT and PATCH, the next question easily emerge:

• laravel resource routes both PUT|PATCH to MyController@update.

Does it means, laravel itself, doesn't actually bother the difference between PUT and PATCH request?

To actually implement this RESTful kind of thought, I'll need to further process it by identifying the exact request method?

    public function update(Request $request, $id)
    {
        switch ($request->method()) {
            //...
        }
    }

@justinmoh

That is not up to Laravel, its up to the developer what he wants to do. Do you want to replace your entire resource with the one from the request or do you just want to update it?

If you really want seperation, you'll need to create all routes by yourself instead of sticking to the resource method.

@justinmoh as @twaileit has said, laravel simply provides the ability to use these methods, it doesnt and shouldnt assume how you use it.

I would strongly suggest NOT merging the methods, only GET|HEAD requests should go to the same controller method.

plus both methods are different in how they should be used, so they should be seperated into distinct actions.

Theres no need to get really complex:

PUT = replace EVERYTHING for the current record with the new values (if not provided they should be set to null), this doesnt have to return a representation as by design we know what the record looks like.

PATCH = update the resource with the values provided and return the updated resource, this returns the resource as the PATCH method MAY update values not originally provided in the request, or perform other actions on the data.

@twaileit , @no12pixels,

Learnt something, got confirmed. Thank you very much.

Did things change?

I am curious to find out how did the PUT and PATCH tech developed since the question was asked.

For example I found this reference to stackoverflow https://stackoverflow.com/questions/21660791/what-is-the-main-difference-between-patch-and-put-request-host but it also seems quite outdated.