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...
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