Simple Service Enterprise - part 3

My previous post showed the fundamentals of information interchange: exposing business functionality, currently encapsulated in the back-end, to the outside world via services. These services are a one-to-one translation to back-end functions, which are one-to-one translations to business process steps themselves: the smallest level of business transaction.
I also showed that the How of exposing these services, e.g. in which format, largely if not solely depends on a healthy amount of opportunism

This post will explain why REST is a bad idea, while taking the previous one a level deeper

I stripped all the technical details in the Adaptive Integrated Enterprise picture above. What remains, is the back-end, and people. The back-end contains functions that people want and need to use - and that is it

Roy Fielding wrote his dissertation entirely in the context of Web, but I see it increasingly being used as a replacement for SOAP and as such apply to the whole field of Integration. I couldn't care less how people will keep themselves busy trying to change the Web's way, but I will assure you that REST has absolutely no business benefits whatsoever with regards to Enterprise Integration. On the contrary, it has no place in it at all

REST advertises two main thoughts: resourcing and CRUD

• "Resources are the key abstractions in REST. They are the remote accessible objects of the application. A resource is a unit of identification. Everything that might be accessed or be manipulated remotely could be a resource. Resources can be static, which means the state of the resource will not change over the time. On the other side other resources can have a high degree of variance in their state over time. Both types of resources are valid types"
• REST identifies four verbs or HTTP methods: POST, GET, PUT and DELETE - identical to C(reate), R(ead), U(pdate) and D(elete), the basic functions of a database
• I leave REST's constraints for what they are: part obvious (client-server and stateless), part irrelevant for Enterprise Integration (cacheable and layered system), part exclusively Web-oriented (code on demand and uniform interface)

I don't get what business benefit identification or use of resources should bring. You can't expose a resource. In Roy Fielding's own words, it was a problem that URI's changed - he wanted them to change as little as possible, even to remain static:

REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created. It is then left to the author to ensure that the identifier chosen for a reference does indeed identify the intended semantics

I have reread that quite a few times, but I just don't get what that means. Functions change when their functionality changes, it can't be helped - and it mustn't be helped. Let me give you some clear examples of that

You're in a hamburger place, and want to order a hamburger. You say "One hamburger please" meaning you call the function / service or URI of hamburger provision with one parameter: a quantity of one.
Suppose that the hamburger place starts selling chicken wings or nuggets and fish filets as well: all of a sudden, their definition of hamburger provisioning has become invalid: in stead of a hamburger place, they're now a food place.
So, the one parameter isn't enough anymore: you also need to provide the type of food. Highly likely even, the function / service or URI of hamburger provisioning will become deprecated and a new one will arise: the function / service or URI of food provisioning, now taking two parameters in stead of one

Unlikely? No, not at all. It's happened to each and every hamburger restaurant.
Will you now call me manipulative because I changed the definition from hamburger place to food place? You can, but it wasn't me who did - it was the place itself that evolved and upgraded its service

But let me amuse you a bit more, and supposed the hamburger place sticks to hamburgers - but from a take-out place they become a bit more of a restaurant, or just decide to become just that little bit customer-oriented than the competition, meaning they'll give you the option: rare, medium or welldone?
Again, another parameter needed for the same function / service or URI

No business offers resources, they offer functions or services: no amount of redefining them as resources or Lawd knows what name is going to change that

So much for resources. They're just another example of a complicated solution to a simple problem - and I'm not even sure I understand the problem. What I do understand, is that this perceived problem doesn't exist in Enterprise Integration - there's a difference between a hamburger place, a restaurant, an a-la-carte and a 5-star dining place, and there's a linear line going through all four from simple service to complex

Verbs, or methods? The same applies, and let me give you another simple example. Can you delete a hamburger in a hamburger place? No, you can only order one, i.e. create. Can you modify it? No, you can only buy it once, or not at all. Can you give a hamburger to a hamburger place? That would be like carrying water to the sea, wouldn't it?
So, inventing all these methods doesn't change the fact that only functions / services are offered by the business

But let's suppose that there's something like a full CRUD URI. Let's take the booking of a hotel room. You create a booking, meaning you pick a room type and date, and pay for it, and the transaction is committed.
Can you delete the booking? Yes, and your money would get refunded. Normally, you pick up the phone and handle this exception on the people level. It would be a very hard case for me to make that this should be an automated service, given the fact that the limited use of this service will simply not ROI.
Not to mention the fact that I'd really like my employees to interact with my customers when the latter cancel a booking - don't want someone to book 50 rooms, pay for them and cancel them all just in time to get all money refunded...
So, modifying would get even harder. Not only is the customer entitled to a refund, but he also has to make a new booking - all in the same transaction, while there is no business relation between the two actions

So, I fail to see how this would be a handy addition to the Web, for even a simple service like booking a hotelroom - the level of trust needed for a fully automated CRUD model simply does not match up to the level of anonymity that exists out here

Is REST a good addition for the Enterprise? Most certainly not. The resource idea is too simple for the complexity involved, and simply irrelevant on a business level. And the CRUD model has of course been in existence for decades, and successfully handled in Integration for equally as long