Secondary question: is the difference (if any) still relevant? (Asking because Ruby on Rails seems to treat both the exact same way)
For further actions, you may consider blocking this person and/or reporting abuse
Secondary question: is the difference (if any) still relevant? (Asking because Ruby on Rails seems to treat both the exact same way)
For further actions, you may consider blocking this person and/or reporting abuse
Mat -
Ty Delargy -
Aya Ragab -
Lithe -
Top comments (12)
It's raining hard. Your roof has holes.
You patch it. Its still
theyour roof, just slightly different.You ditch the roof and put another one. It's still your roof, but totally replaced.
Edit: grammar
hmm nice way to PUT it !
Nice example! Thanks :)
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:
I'm not sure how much this distinction is really respected when people develop REST APIs in the real world though.
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.
I found this piece of information regarding Rails specifically: weblog.rubyonrails.org/2012/2/26/e.... It sounds as though Rails uses
patchas the default verb now for update semantics...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.
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,
GETshould 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 aGETrequest to be issued that supplies a token. On the server side, if the token is valid, something like aregistration_confirmedflag is set totrue. 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...
Yeah, most APIs are RESTish at best, which is fine by me to be honest
Rails is modern? 😨
Well, current if you prefer. I meant frameworks that are actively used today in web development (and Rails definitely is).
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.