Explain the difference between PATCH and PUT Like I'm Five

Secondary question: is the difference (if any) still relevant? (Asking because Ruby on Rails seems to treat both the exact same way)

Comments

[John Alcher]

It's raining hard. Your roof has holes.

You patch it. Its still the your roof, just slightly different.

You ditch the roof and put another one. It's still your roof, but totally replaced.

Edit: grammar

[AISHWARYA PATTWARDHAN]

hmm nice way to PUT it !

[Quentin Sonrel]

Nice example! Thanks :)

[Nested Software]

It's good to keep in mind that REST is built around the idea of "documents." As a result, it doesn't always map very well to application logic. In any case, keeping this document-oriented model in mind makes it easier to understand the difference. It's as @alchermd says:

• PUT: Replace the current document with a brand new document
• PATCH: Modify only a part of the current document.

I'm not sure how much this distinction is really respected when people develop REST APIs in the real world though.

[Quentin Sonrel]

That's what I though. As I said, it seems like some modern web frameworks (such as Rails) treat PUT and PATCH the exact same way, making no difference at all, hence my second question about the relevance of it all today.

[Nested Software]

I found this piece of information regarding Rails specifically: weblog.rubyonrails.org/2012/2/26/e.... It sounds as though Rails uses patch as the default verb now for update semantics...

[Quentin Sonrel]

In any case, when you use Rails to generate a controller (or scaffold) you see that it will route PUT and PATCH requests to the same controller anyway. This can be confirmed by trying to send a PUT request with only some of the parameters, it will work the same way it would have if you used a PATCH request.

[Nested Software]

An additional thought: In terms of relevance, a given API provider doesn't have to conform to REST semantics in a pure way. It's really up to each provider to decide how their API works.

For example, GET should not change any application state. It should just retrieve some data. However, there can be exceptions to this rule in practice. For example, let's say your application sends an e-mail asking users to confirm their account registration by clicking on a url contained in the message. From the point of view of the end-user, the quickest and most convenient way to do this would be for the url to cause a GET request to be issued that supplies a token. On the server side, if the token is valid, something like a registration_confirmed flag is set to true. This way, when the user clicks the url, their registration is immediately confirmed.

In such a case, the request does not conform to the normal expectations for GET, but the alternative may be less convenient for the user: The url would have to send the user to a form with a "confirm" button on it first. Then the user would have to click this button for the server to confirm the registration. Some sites in fact do things this longer way, but not all.

I think it's not unusual to run into such pain points, because the paradigm of building applications doesn't map perfectly to the document-oriented paradigm that many Web technologies and standards have been built around...

[rhymes]

Yeah, most APIs are RESTish at best, which is fine by me to be honest

[1hko]

Rails is modern? 😨

[Quentin Sonrel]

Well, current if you prefer. I meant frameworks that are actively used today in web development (and Rails definitely is).

[Nate]

I like to think of most of the verbs being like street addresses. GET PUT PATCH DELETE. but the odd one out is POST. it's used to do something that might not have an address or never would.

GET /article/1
PUT /article/1 (could create or replace)
PATCH /article/1 (maybe it has to exist already?)
DELETE /article/1 (do we just ignore if it doesn't exist?)
POST /article/action (maybe I'm not using GUIDs and have to POST new articles instead of giving it the street address)

Most importantly it should make sense in your app how the verbs are used. Prefer to stick with common conventions, if they exist.