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.
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...
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...
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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 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.