REST definition and its place within Enterprise Integration

In a previous post I explained why REST is useless when it comes to Enterprise Integration. Even though at the very beginning I explicitly stated that

Roy Fielding wrote his dissertation entirely in the context of Web

and that

REST has absolutely no business benefits whatsoever with regards to Enterprise Integration

I got surprised to say the least by comments in various channels, most from professionals, even vendor representatives. Tech people, but nonetheless

The most commonly heared argument was that I misrepresented REST or even clearly showed my lack of understanding of REST, upon which my simple response was: can you please point me to a few articles or posts that respresent your understanding? but surprise you or not, the responses to that were either absent, or absurdly far from being to the point (e.g. "your post doesn't even make me want to help you")

So, I show you what REST is, according to Roy's dissertation, and Wikipedia, and then will disect that with regards to Enterprise Integration, and see where the twain meet. Does that seem fair? I most certainly think it does. If it doesn't, point me to definitions that better suit your understanding of either, please. This is not meant as a debate, but a dialogue (as usual). If you don't want to participate in the dialogue, fine - don't even bother to react or comment

The definition of REST is kind of hard to come by. Yet, according to the magnificent Wikipedia, here are the constraints of REST (shortened yet literally quoted by me for brevity):

1. Client–server: A uniform interface separates clients from servers
2. Stateless: The client–server communication is further constrained by no client context being stored on the server between requests
3. Cacheable: (...) Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests
4. Layered system: Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. They may also enforce security policies
5. Code on demand (optional): Servers are able temporarily to extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript
6. Uniform interface The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below

Here's that "below"

1. Identification of resources: (...) For example, the server does not send its database, but rather, perhaps, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8
2. Manipulation of resources through these representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so
3. Self-descriptive messages: Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cacheability
4. Hypermedia as the engine of application state: Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular actions will be available for any particular resources beyond those described in representations previously received from the server.

You find very little of all of that when you search the Web. What you do find, is an insistency on CRUD to use with HTTP. Which is odd, because CRUD isn't even part of REST. It's unclear where it got added, how and by whom, but here's what the common misunderstanding is:

• 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

Roy explicitly disagrees with that in his March 2009 post:

Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST

So, CRUD's out the door, leaving the 6 constraints and the 4 guiding principles


Let me comment on REST's constraints first, from an Enterprise Integration point of view

1. Client–server: A uniform interface separates clients from servers. No, what Roy said was "By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components". And that makes perfect sense in EI. But uniform interface? That is a lock-in no one can afford - functionally uniform, yes I agree. But technically?
2. Stateless: The client–server communication is further constrained by no client context being stored on the server between requests. I certainly hope so. Cache prevents any means of scale
3. Cacheable: (...) Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. I never got around this one. You can't be stateless and allow for cache at the same time, client-side nor server-side. This is a void in Roy's plan
4. Layered system: Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. They may also enforce security policies. A clear deeply infrastructural technical addition, again focussing on speeding up the Web. Enforcing security policies? Only when those have been agreed upon beforehand, I hope - it would be devastating if your request bounces somewhere off intermediary server 5 or 6. Shared caches? Again, this defies the notion of statelessness
5. Code on demand (optional): Servers are able temporarily to extend or customize the functionality of a client by the transfer of executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript. In a Web context, this may make sense. In an EI context, it won't: you offer back-end services, and that's it. Can't temporarily offer more to some clients, and then take away those privileges again
6. Uniform interface: The uniform interface between clients and servers, discussed below, simplifies and decouples the architecture, which enables each part to evolve independently. The four guiding principles of this interface are detailed below

So, out of 6 (or is it 5) constraints, only one might work for Enterprise Integration. The constraints are mostly focused on caching, but that doesn't come as a surprise:
Roy Fieldings's dissertation is 12 years old now. I read the dissertation, from beginning to end. It taught me among others that

REST enables the caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meeting the needs of an Internet-scale distributed hypermedia system. (...) REST elaborates only those portions of the architecture that are considered essential for Internet-scale distributed hypermedia interaction

Roy was mainly concerned about Web performance and thus wrote his dissertation. Did he mean it to be used as a great paradigm for Enterprise Integration? If any, he certainly didn't state so. I'll take my chances and state that he most certainly didn't, and still doesn't.
Anyway, there are 4 guiding principles left

Let me comment on REST's guiding principles, from an Enterprise Integration point of view

1. Identification of resources: (...) For example, the server does not send its database, but rather, perhaps, some HTML, XML or JSON that represents some database records expressed, for instance, in Finnish and encoded in UTF-8. Absolutely agreed. Decoupling between data in the database and the form it is requested in or even responded in, is without questioning
2. Manipulation of resources through these representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource on the server, provided it has permission to do so. Roy says "Information hiding is one of the key software engineering principles that motivates the uniform interface of REST. Because a client is restricted to the manipulation of representations rather than directly accessing the implementation of a resource, the implementation can be constructed in whatever form is desired by the naming authority without impacting the clients that may use its representations" which makes sense, and relates back to decoupling, and the use of an interface
3. Self-descriptive messages: Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cacheability. This is again strictly Web tech related, and touches on the fundamental differences between REST and Enterprise Integration: REST is written for the Web, where unknowns interact with unknowns. Enterprise Integration is all about predefined agreements between knowns
4. Hypermedia as the engine of application state: Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g. by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular actions will be available for any particular resources beyond those described in representations previously received from the server. Again, strictly Web context. It is difficult to follow which parts of REST are about conversations, and which are about request-reply during those conversations

It's not my intention to invalidate REST. It is my intention to really get behind its definitions, and its benefits, and see where those can be useful for Enterprise Integration. Call me narrow-minded but that's all I'm interested in at the moment. The use of REST for the web? Not my area of expertise, but I believe REST is already widely implemented there.
I think I have done a fair amount of research in order to find out what REST really is about - I even found that one if its pillars, CRUD, isn't part of REST. It got added to it at some point, certainly not by Roy Fielding himself

Is REST useful for Enterprise Integration? Certainly not on the wide basis that Enterprise integration must operate on: multi-channel, multi-message, multi-device, multi-platform, multi-industry. In short: no, absolutely not.
REST focuses on caching, layering, dsitributed hypermedia interaction for an Internet-scale use. That dwarfs Enterprise Integration in size, of course.
But there is also a fundamental difference between the Web and Enterprise Integration. A2A, B2B, B2C: these all operate on predefined, fixed agreements. Can't just plug into the Matrix and try to figure out for yourself what the functionality is of the return of a function - that's the epitome of making assumptions

Where ever I look, REST is aimed to increase performance within an Internet-architecture by enabling caching, layering, intermediate services. Its second aim is to diminish or even avoid rework if parts change their definition or functional form, by using representations rather than the real deal.
The first goal is absolutely unrelated to any form of Business Integration. If there is any latency within Enterprise Integration, this is not the way to solve it - I'd first start to use a better tool.
The second goal is outright forbidden to use within Enterprise Integration. I explicitly want to subscribe to service A version 35 that provides me with information X.29a. I absolutely do not want that to change without my prior knowledge

The main difference between REST and Enterprise Integration is that the former runs on the Web, serving humans. The latter runs inside companies, serving machines. The first must be highly flexible to cope with the inherent dynamics, the second must be extremely rigid to enforce the agreed starics.
Their common ground? Basically, little to nothing