Mark Baker makes an interesting distinction in my wRESTling with tuple spaces...
Patrick seems stuck with how to reconcile his position that generic abstractions are a good thing, but that systems should be built independent of the protocol. Note to Patrick; this is all well and good for transport protocols, but application protocols define the abstraction; for them, protocol independence requires that you disregard that abstraction.
This distinction of transport protocols vs. application protocols is exactly what I am wondering about REST. As I read the definition of REST, the architectural style being described is for a transport protocol rather than an application protocol. Not much is said really about the behaviors of the client or the server. Even when you bring HTTP per se into the definition of REST, Fielding makes a somewhat confusing statement about transport protocols...
HTTP is not designed to be a transport protocol. It is a transfer protocol in which the messages reflect the semantics of the Web architecture by performing actions on resources through the transfer and manipulation of representations of those resources.
Is it a transport protocol or not? Let's ignore that and pursue the part about "performing actions on resources" because that *does* seem to be about an application protocol. Fielding continues...
It is possible to achieve a wide range of functionality using this very simple interface, but following the interface is required in order for HTTP semantics to remain visible to intermediaries.
And so this is where I begin to have problems with REST, as I read it, as an application protocol for distributed system coordination. The problem is not that it is inappropriate, but rather that it is too vague.
I don't mean "vague" in a derogatory manner. What I mean is exactly what Fielding writes, i.e. it is possible to implement a wide range of functionality using this very simple interface.
How is this different from the tuple space interface? I have written, and many others better than I have written, that it is possible to implement a wide range of features using the very simple tuple space interface.
The difference is this: the HTTP interface is vague and the Linda interface is specific. Linda has precise, simple semantics. The possible range of behaviors exhibited in Linda-based systems benefit from being layered on *top* of those precise, simple semantics.
HTTP, on the other hand, has to be *elaborated* into something more specific in order to have a useful meaning as an application protocol. WebDAV is an example of such an elaboration.
Every web site that implements custom behavior using forms with GET or POST is an example of the open ended nature of HTTP per se. The architectural style of REST supports the HTTP transport protocol underlying these forms moving across the web, but the application protocol, that is, the behavior of the forms on the client and especially on the server is defined (at least in code) by each specific instance.
Distributed systems wishing to use HTTP, or more generally REST, to perform coordinated work will therefore require some more specifically defined application interface than that provided by REST, or that provided by HTTP.
WebDAV is one option as stated already, and it is proven to be viable in some specific cases. I don't believe the full range of systems that can be usefully built with WebDAV has been exhausted. By the same token, neither do I see a lot of evidence of that range being nearly as broad as that of Linda tuple spaces.
Vanessa Williams provides an elaboration of HTTP for a tuple space application protocol. As I understand REST this should therefore provide the application protocol of a tuple space on the architectural style of REST using the HTTP transport/application protocol mix. In this case the advantage of using REST and HTTP is supposed to be found in the hardware and software that would already be in place between the client and the server.
I think and hope this is fairly accurate. I am eager to be clued in further by Mark and others. I am still unsure that this advantage is significant over a less pure elaboration of HTTP, as in XML-RPC or the arguably more RESTian SOAP. I think there is a lot to be said for something else altogether as a transport for tuple spaces, in particular Jabber or perhaps Spread. The bottom line is the usage models of distributed systems coordination would benefit from a well defined, simple, axiomatic application protocol, but the best transport protocols *will* have to evolve just because the usage models themselves will have to evolve. For all but a handful of services (e.g. Google), they just may act nothing like today's web.
No comments:
Post a Comment