|
> Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate. And just like with POST, whether or not this is actually the case in a given API, depends entirely on the server-side implementation. Look, I get it. We want to make rules. Rules are good. Rules define things. But in a world where so many "REST APIs" are actually "RESTful" or REST-ish, or "actually about as REST as a Pelican, but we really liked the sound of the acronym", I wonder if adding one more rule to the pile is really going to substantially change anything. A majority of APIs don't even use all of the existing HTTP verbs, or HTTP response codes for that matter. And every API is free to make up their own rules. I had the dubious pleasure of consuming APIs that required GET with both a body and urlparams, and which returned 200 on error, but with an `{error: {...}}` object in the body. The crown jewel so far, was an authentication system that had me send credentials as multipart/form-data, with a PUT request (because you inPUT the credentials, see? Not a joke, that was the rationale given to me by the dev who made it.) |
That you cannot rely on consistency is not a reason to have none at all.
Destructive actions can and are also hidden behind a GET. When such an endpoint gets called indiscriminately by the rest of the internet it usually becomes the faulty implementation's problem.
Presumably the same would be true for QUERY.