How and why common sense will beat REST

In my previous post I described how REST would replace SOAP. If you paid close attention you will have noticed that I actually didn't say anything in favour of REST, but everything at the expense of SOAP.
Because it indeed seems like REST will be the new SOAP - which is in contradiction with the idea that today's Enterprises that have any form of Service Oriented Architecture will replace their current implementations by those fit for the future

Because "REST" just doesn't make any sense in that context. Mind you, I'm talking about the REST that the low-level techies hijack; exactly what I described, i.e. JSON with the four HTTP verbs. Not the REST as Roy Fielding intended, i.e. a verb-independent style. Apart from all the heavy caching on every side of any connection, which really enabled the scale he was looking for. Without cache, there would be no Internet. Period.
And in case you want to know what Roy thinks of the current hijacking of REST, just read this and this

REST is meant for hypertext-based client-server interaction where the uncertainty is high, i.e. where client and server have little to none knowledge of each other and eachother's intentions. It is excellent to handle unpredictability such as which piece of information will be requested or presented next, and when I compare it to the context of Enterprise Integration, I must say that they compare to each other as day and night. Or night and day - which ever you prefer. Where an Enterprise is straight-jacketed into business rules and really doesn't like exceptions to those, even the entire concept of rules and exceptions is absent in REST. REST is all about state, and doesn't care where a resource resides or comes from, or even which version it is: its identifier stays the same.
In Enterprise Integration on the other hand, an order from client A can (and usually will) look entirely different from an order from client B, and must be treated in a completely other way. Resource representations without knowing what lies beneath? Version numbering is of the utmost essentiality in Enterprise!

So, REST and Enterprise Integration have nothing to do with each other, regardless of the hordes that embrace and adore contradictory notions such as REST-based SOA, or SOA-REST, or use REST API's to describe pretty much anything that exactly resembles JSON over HTTP without anything else (or that while including the four HTTP verbs). All those people are either ignorant and choose to stay so, or malign and intentionally hijacking the term REST "just cuz it's hot" to fit anything they happen to be able to sell at that very moment. Is there any grayscale in between? I'm not so sure that there is much

In this context, an interesting and spot-on post was written by Steve Jones. I'll just take one quote to sum it up:

The focus of shiny technology over business outcomes and the focus of short term coding over long term design will ensure that IT departments get broken up and business folks treat IT as a commodity in an ever growing way

Steve describes how shouting has come to replace thinking in IT. Facts, reason and experience have been replaced by debates, emotions and loudmouthing. It worries me that especially IT professionals take this course in a growing fashion; I can't wait (trust me, I can) to be told again that I got REST completely wrong - my answer will again be: "Please show me the right definition of REST and I might change my opinion on it", which will highly likely be met with either silence or one of those famous counter-questions.
There are exceptions to that rule, but it's the rule and those are the exceptions, als - not vice versa

Where I see "REST API's" being particularly popular is among coders who now can hard-couple applications together with just a bit of Java and not much else - instantly connect to the outside world with just a few clicks and ticks. Yes, they now can build point-to-point interfaces on an increasingly growing scale, a few times faster than before! They break more than a few REST rules in order to be able to even do that, but, they manage.
Which is a costly, inefficient and unwise approach of Integration, and that was proven decades ago - which highly likely precedes their experience or knowledge. It is a short-sighted approach that will give us all a future where we can replace the "RESTful services" of today and tomorrow in 2-5 years from now. It will certainly keep the profession alive and guarantee me (among others) a big flow of income, but it's a waste of time and money and hurts business continuity.
The point is not to write code to get what you want, the point is to write code so you don't get what you don't want. What if such an "interface" breaks down? Functionally, technically? Temporary?
Not wanting to repeat myself, let me point you to my answer to that right here

The addition of the zealous use of the four HTTP verbs and the extreme focus on it bothers me most though: to me that is so obviously wrong (to Roy as well, by the way) that I'm just going to have to explain that here:

If you have any database experience, you'll know of CRUD: Create, Read, Update and Delete. I compared that to HTTP's PUT, GET, POST and DELETE. You'll know that these database commands are entirely different (forgive me the pseudo SQL, I know pseudo code is a evil incarnate mortal sin):

• INSERT INTO EMP (EmployeeID=2745, EmployeeLastname="Linsen")
• SELECT * FROM EMP WHERE EmployeeID = 2745
• UPDATE EMP SET EmployeeLastname = "Linssen" WHERE EmployeeId = 2745
• DELETE FROM EMP WHERE EmployeeId = 2745

See how these commands are different?

• In order to Create, you need values - enough values to satisfy the mandatory conditions given the requirements in place
• In order to Read, you need to identify what you want to read. You need an identification key, range or keys, or wildcards
• In order to Update, you need a combination of what is required for Create and Read: you need to identify what you want to read, and enough values to satisfy the mandatory conditions given the requirements in place
• In order to Delete, you need to identify what you want to delete

It is obvious what you want, just by looking at the parameters you provide. The words itself are there merely for legibility, or fun as some would say. Because basically these commands could be:

• EMP (EmployeeID=2745, EmployeeLastname="Linsen")
• EMP WHERE EmployeeID = 2745
• EMP EmployeeLastname = "Linssen" WHERE EmployeeId = 2745
• EMP WHERE EmployeeId = 2745

The first one is obvious: you provide values and no identification, so this is a Create method
The second one is not so obvious: you provide an identification, but do you need retrieval or deletion?
The third one is obvious: you provide values and identification, so this is an Update method
The fourth one is not so obvious: you provide an identification, but do you need retrieval or deletion?

So you would need a way to distinguish between Create and Delete, but other than that, which ever method you want to use is blatantly obvious if you look just at the parameters supplied.
Let me rephrase that: which ever method you want to use becomes blatantly obvious by looking just at the parameters supplied

So no need for the HTTP verbs or methods. I'll make an even better case for that:
Suppose, that you goof up and mix the methods invoked with parameters supplied. Here goes:

• INSERT INTO EMP (EmployeeID=2745, EmployeeLastname="Linsen") WHERE EmployeeID = 2745
• UPDATE EMP SET (EmployeeID=2745, EmployeeLastname="Linsen")

The first one seems to be a Create statement, but has an identification as well - which is totally wrong of course, because you can't reference something before it's been created. That one could go either way: if the reference exists, the record will be updated with the values, if it doesn't, it will be created - although technically there should be an error if you want to Create something that already exists, just as when you want to update something that doesn't.
The second one is an obvious Update statement, or is it? It's lacking the identification. The record could be inserted if it doesn't exist. Hack, it could even be updated if one of the parameters sits on a unique key field - but that would be sci-fi databasing so let's just ignore that option

So the verb or method you use isn't really leading in execution of a method: it's the parameters instead that determine what can and will happen, or could and would.
Which is good of course, because as your web server will highly likely pass these requests onto the back-end applications (which most of the time will not support HTTP, but another transport protocol, usually some queueing system), it would be a shame if their beautiful method had to somehow be glued to the request, now wouldn't it?
Never, never ever, write content-sensitive stuff on an envelope - it will get lost in the process


Where has common sense gone? What really is the great business value of REST, if any? The hijacked REST I mean, with its focus on the four verbs - which isn't in Roy's dissertation, the focus on JSON - which isn't in Roy's dissertation, its lack of use and disregard for caching - which is in Roy's dissertation, and gross neglect of resource identification by using API versioning

If you want a cat, go buy a cat and treat it like one. Don't call your dog cat, make it act like a cat, and then say "well it's not really a cat you know, so it's okay".
Stop hijacking REST.
Whatever it is that you do, just call it scribbling, tinkering, fiddling, dabbling, doodling, messing around. But not REST