The whole history of computing is one of redefining words. Really, who cares if you call it a Unit Test or a Frisbee? You certainly don't have to know the name to come up with the concept and find it useful.

REST is an unfortunate name for a great movement - unfortunate because the original "REST" paper was the same kind of overengineered crap that REST-the-movement was a rebellion against. So now the highly paid consultants are peddling their overengineered crap and calling it "REST" and on a literal level they're right. But the solution isn't to argue about what is and isn't REST - it's to consider the actual behaviours (HTTP verbs, content types, HATEOAS) on their own merits.

I believe in using HTTP verbs to mean the things they say, but I think HATEOAS is actively harmful. Am I doing REST? Who cares!

I always wonder - is there a reason to use HTTP verbs?

It seems to me using POST to request information is better than using GET - instead of putting a url in the GET request, put it in the body of the POST (plus anything else you want).

I thing a decent JSON-based approach might be easier than bare http, which lacks things that might be needed.

If you treat your endpoints as resources, and if you think of the verbs as the operations you can perform on those resources, then you have a discoverable interface. IF you limit everything to a single verb, then you have to define a series of operations...

But this isn't the only way an interface could be discoverable - what about a schema (or a good api doc for humans). This way also couples api to implementation - what if I want different verbs? Suddenly, we stray from the discoverable path.

And that's fine, and nobody says REST should be the way. But then call it for what it is: An HTTP API.

But this post isn't so much about REST (albeit sparked, once again from it), but about how people use the term pragmatism to get away from truly understanding something.