All the confusion and controversy around REST design isn’t really new. If you set aside the annoying aspects people throw out of nit-picky URI design restrictions and how to cram API methods into HTTP verbs, it really boils down to the age-old argument between OO and procedural (or structural) programming.
Most of the developers I’ve worked with believe they are doing OO programming, but in practice what they do is create some lightweight data objects that only have getters and setters, but no functionality. Then they write a good, old-fashioned structural programs. That is, broken up into function and control structures like loops and if-thens, but they chunk it up into Objects with names like “Handler” or “Service” or “Util”. They could have written the same code in Pascal, and maybe even BASIC.
I see extremely little code where the developer actually models something in the system as a thing, with encapsulated data and methods on that data. The libraries I work with are good at that, but my co-workers just aren’t.
Oh, and the first thing they do in any project is define the key abstract base classes so they have a convient place to squirrel away any common crap they see in their code.
I call this practice “compiled scripting”. They could just have easily written the same program in any of the scripting languages, except they’ve added a compile cycle to their development.
Suddenly the idea of an API oriented around Resources comes along. And Resource is just another way to say Object. Except, of course, that each Object is only allowed to have 3 methods — or 4, if you grudgingly include POST.
So this is just a huge leap for almost every developer that I’ve worked with. Suddenly they have to stop thinking of their API as a list of procedures (from structural programming), and they actually have to start doing design oriented around resource objects. And what’s worse, those objects aren’t allowed to have a big shopping list of methods because of the Uniform Interface constraint.
So if OO is a really huge pill for a lot of developers to swallow, imagine them getting their arms around something like REST.
In my current shop, the politics are so dumb and nasty that I’ve just given up on trying to bring up any sort of ideas about real modelling anymore. I just try to apply light pressure and keep the procedural APIs from being too bad. There are some good practices around procedural code that will make your life a lot more sane.
In the end, I have doubts about the interpretation of REST that the experts are pummeling us with these days. I think it’s definitely a developing area of thought, and it’s going to evolve. Some of the points we argue fervently today are going to fall away, and the silly things we refused to take seriously are going to be the fervent arguments of tomorrow.
But at the core of it all, is this ancient war between nouns and verbs. It’s a raw, almost hereditary conflict over whether data structures or procedure invocations should be supreme. I, for one, am a weary warrior in that conflict, longing for the day I can bend my sword into a plowshare and just write some f-ing code without all the drama.