When the Web Services Architecture WG closed down, I took the
opportunity to
ask
working group members what their reasons were for not using REST
as a base for Web services. I continue to hear, on an almost daily
basis, about how the Web is for humans, so that’s what I expected to
hear. Instead, to my surprise and elation, I heard comments such as
this
from Roger Cutler;
Although I have not put the time and effort into studying it enough to
be very sure, what I have seen of the REST-like solutions you have
proposed or described to problems addressed by Web services indicates to
me that it COULD have been done that way and that it would have worked.
In fact, it’s even possible that it would have worked better and that it
would have been better had it been done that way. I don’t really know
that this is the case, but I think it’s possible it might be. I also
think it’s utterly irrelevant. What’s done is done, and the world ain’t
goin that way. In hindsight there are many, many places in the way all
sorts of things have developed in the world that might have been done
better or more directly. The progress of human affairs is imperfect at
best. I personally participate in those imperfections.
A couple of other people responded, basically agreeing with Roger.
This is an important milestone, I’d say. It seems to signify the end of
the “REST Wars”, as some Web services folks now accept that there are
RESTful solutions to application-to-application integration over the
Internet. Stage one is complete.
Stage two – which I’ve been arguing alongside stage
one, but can now apparently focus upon more intently – is about software
architecture; that unless your architecture has the properties your
environment requires, you will fail. Even pervasive agreement
on an architecture lacking in those properties is an insufficient condition
for success.
Onward to stage two! Let’s hope this one doesn’t take another
four years
of effort (that message was my first message critiquing Web services, AFAICT).
Savas responds,
noting he and his co-authors had previously patched that portion of their paper. Great. Here it is;
There have been proposals for naming and uniformly providing access to resources, such as the REpresentational State Transfer (REST) [24] model. However, since REST depends on HTTP (or more accurately a protocol with HTTP-like semantics) it is protocol specific and hence unsuitable for heterogeneous systems like the Grid. It also requires a particular interface to be used with the exposed resource, hence coupling identity and interface.
In practical terms, this means that HTTP proxies must be placed in front of non-HTTP aware resources (e.g. FTP).
My first comment is that it appears contradictory; the last sentence talks
about how other protocols can be supported, yet the previous paragraph still
claims it’s protocol specific.
Another comment concerns the last sentence of the first paragraph; I think
Savas probably got that from something I said to him, but I should elaborate.
Identity and interface are coupled only in the sense that there’s a default
association of URI scheme to protocol. But that association is not to the
exclusion of
other protocols. Consider an ftp URI; alone in the wild, that URI maps to,
basically, the FTP RETR method. But one can use that same identifier in the
context of any system whose interaction semantics can subsume those of FTP,
for example, HTTP. I wish there were another example of systems that it
could have been subsumed by, but I can’t think of one. And FWIW, what’s
special about HTTP here is that, for *all* URIs, HTTP is an answer to the
question “Name a protocol, other than the one suggested by the URI
scheme, which can be used to interact with the resource identified by this
URI”. That’s why HTTP is so special (and another explanation for why
protocol independence is such a harmful concept).
Good stuff though. I’m really very encouraged by this work, and WS-RF too,
as from my POV, both seem to be getting closer to the sweet spot of the Web as
large scale integration solutions.
Bill de hÓra on Web services;
In early 2004, the Achilles heel of web services is the complexity resulting from the sheer volume and lack of coherence in the web services specs and a lack of architectural guidance from the folks generating them
Yup, big +1
And now that the Web Service Architecture WG is closed, I wonder where this
guidance will come from? That’s why I’m honestly disappointed at its closing,
despite voting against its chartering as a W3C AC rep a couple of years ago.