REST is the new SOAP

REST is the new SOAP
medium.com

Nothing bothers me more than an idempotent request (e.g. a search query) using POST. If you design your API starting with "what should happen if the client makes this request multiple times?", then it becomes much easier to model with HTTP.

HTTP 401 Unauthorized actually means Unauthenticated. 403 Forbidden actually means Unauthorized. Yeah, it is a bit of a mess but the referer header is misspelt so what can you do.

"I don’t care. Trees are recognized by their own fruits. What took me a few hours of coding and worked very robustly, with simple RPC, now takes weeks..."

He seems unhappy that REST doesn't work the way his familiar tool (RPC) does. I myself worked with middleware-messages-over-TCP systems for a decade before switching to web apis. I don't have this issue. And I personally don't follow the "holy specification", and REST works just fine for me.

I've seen this argument before (I've even made this argument before), but I'm becoming increasingly unconvinced by it. Let me explain my thinking:

1. If there's ANYTHING that sets REST apart from a generic HTTP-and-JSON protocol, it's the focus on basing endpoints off the concept of resources and collections, and using HTTP verbs to determine the type action to be performed. (And also, possibly, internal hyperlinks, but nobody seems to actually pay attention to that part.)

2. Depending on your application, somewhere between "some" and "most" of your API traffic doesn't deal things that easily map to resources and collections, doesn't involve actions that easily map to HTTP verbs, or both. One of the most common examples is sessions. When you log in, are you creating a session resource? Is that a sub-resource of the user resources, or an independent collection in its own right? Or are you actually retrieving a session token from the user resource? When you log out, are you actually deleting that session? Or updating the session to remove its authentication?

3. It's easy to say "prioritise clarity to humans", and I totally agree, but in that case, you'd just have a /login and /logout endpoints, you'd do a POST to the former with a valid username/password to login, and a POST to the latter to log out, the end. That's super clear, and super usable, but nothing about that is RESTful. And the same thing comes up over and over again. For every time I find myself doing simple CRUD operations on a collection of concrete resources, there's 10 times I find myself needing to do complicated, ambiguous operations on things which aren't.

4. But if I relax and focus on making a clear, usable API, then almost by definition I have to do so by not being RESTful. It's easy to say that you shouldn't get religious about HTTP verbs and URL structures (and I agree), but since HTTP verbs and URL structures is 100% of what people seem to mean by "REST" in actual practice, then...in what sense is REST a good idea? It's like drinking rum and coke without the rum...and the coke. What's left? Nothing Roy Fielding would recognise, in my view.

I'm happy to entertain the idea that REST is useful when you are doing CRUD operations on simple, concrete resources (updating prices on an online store; posting comments to a blog; whatever). But in my personal experience, most people seem to view REST as the ideal way to handle making an entire API, even the bits that are clearly nothing more than RPCs triggered via HTTP.