09/05/08 :: [REST] A question of Style [permalink]
Evidence continue to mount that the (other) REST is a complete fraud (again, nothing that I say applies to the Web (Roy's) REST.
Yesterday, Aristotle commented that :
WS-*, in contrast, is simply the absence of any style, the null architecture. It sets forth no constraints and therefore can make no guarantees. If you use WS-*, you can design your system in any way at all, and so all of the properties of your system are up in the air: the burden is on you to design it so that it exhibits any particular property or to prove that it does. If that works for you: great.
Since I hate to proceed with logical arguments, I took the task to re-read some of Roy's Thesis to better understand Aristotle's comment.
To be very clear, I always expressed that Roy's REST was a great concept (it gave us the Web, so who would I be to say otherwise), but what I argue is applying Roy's REST, as-is, for Server-to-Server communications (i.e. the construction of "connected systems") is quite a stretch of imagination to say the least. I don't think Roy ever said something different.
If you want to convince yourself, I would recommend you read chapter 3 of his thesis where he goes through the different network-based architectural styles:
What did Roy had in mind?
By characterizing styles by their influence on architectural properties, and particularly on the network-based application performance of a distributed hypermedia system, we gain the ability to better choose a software design that is appropriate for the application.
But he is prompt to point out, with the integrity of a scientist, that
[his] evaluation [of the styles] is specific to the needs of distributed hypermedia
If this is not clear enough, he adds:
For example, many of the good qualities of the pipe-and-filter style disappear if the communication is fine-grained control messages, and are not applicable at all if the communication requires user interactivity. Likewise, layered caching only adds to latency, without any benefit, if none of the responses to client requests are cacheable.
And again, always with the integrity of a scientist he adds:
[I suggest] creating separate classification tables for each type of communication problem [other than the needs of hypermedia]. Example problem areas would include, among others, large grain data retrieval, remote information monitoring, search, remote control systems, and distributed processing.
But of course, what I write about REST is just a rant. The reality is that the RESTafarians have either never read Roy's Thesis or they are simply in to bolonize our industry with an otherwise epic piece of work, Roy's Thesis. Their arguments have simply no foundation.
But, hey, if your goal in life is to achieve "Accidental Programming" why would you care about these fine prints in Roy's Thesis? Why wouldn't you spend all your time talking about the merits of caching, when hardly anything can be cached in the enterprise? Why would you not say that WS-*.Style == null when in fact the peer-to-peer style is the foundation to Connected systems.
If you still doubt, please read Chapter 4 of Roy's Thesis,
The design rationale behind the WWW architecture can be described by an architectural style consisting of the set of constraints applied to the elements within the Web architecture.
So what is the WWW?
What was needed was a way for people to store and structure their own information, whether permanent or ephemeral in nature, such that it could be usable by themselves and others, and to be able to reference and structure the information stored by others so that it would not be necessary for everyone to keep and maintain local copies.
If you want to understand the genesis of Roy's REST constraints, read on:
Hypermedia was chosen as the user interface [surprising isn't it?] because of its simplicity and generality...
Hypermedia is defined by the presence of application control information embedded within, or as a layer above, the presentation of information [yes the presentation of information !]. Distributed hypermedia allows the presentation and control information to be stored at remote locations. By its nature, user actions within a distributed hypermedia system require the transfer of large amounts of data from where the data is stored to where it is used. Thus, the Web architecture must be designed for large-grain data transfer.
The usability of hypermedia interaction is highly sensitive to user-perceived latency: the time between selecting a link and the rendering of a usable result. Since the Web's information sources are distributed across the global Internet, the architecture needs to minimize network interactions (round-trips within the data transfer protocols).
But of course, it was totally illegitimate to create something like WS-* when RESTful HTTP was designed with this kind of requirements in mind. But of course, serendipitously, Roy's created a complete programming model for the enterprise including an hypermedia-based data model and a "uniform" interface that matches all possible interactions.
Stefan, Tim, Steve, Anne, Aristotle and others... when will you stop misleading our industry? What is your point? What is your goal? Don't you think we have enough to deal with in IT to avoid having a little clique pollute our industry with bogus rationales and fantasy claims? Isn't there enough evidence that:
a) Roy's REST was never designed to tackle the kinds of problems that WS-* tackles (and vice versa)?
b) If you want to solve these problems you are going to create REST-* and it won't look much different than WS-* since WS-* is about layering the semantics that are missing in HTTP to address some other communication problems
You don't like WS-*? fine, build your own, but at least have the integrity to say so. Don't tell people that they are wasting their time and money, specially when your only proposition is to waste more of their time and their money.
So, I know, I even understand, that this clique thinks it has no other choice than the "fuite en avant" strategy, hoping that some miracle will happen an indeed HTTP is here to solve serendipitously all "distributed computing" problems. My only question to you is, don't you think that with the current state of our industry our time would not be better spent by understanding that resources, actions and services don't compete with each other but are part of the same programming model? That would be the courageous choice. But hey, courage is not really an attribute of value these days.