A gem from Mark,
discussing the sad state of affairs with
Web services architecture. Of course, he manages to do it without
sounding like he’s criticising. How’s he do that? Gotta get me
some pointers. 8-)
If Web services is a bag of specifications that only constrain you by accident (“it must be XML,” “it’s message-based,” “the basic unit of interaction is the ‘operation'”) then Web services has no architecture, at least in this sense of software architecture*; it’s just flinging messages around.
Pretty much, yep. Didn’t I
point that out
already? 8-)
But as a meta point, isn’t it nice how clear things become when using the language of
software architecture
to examine, well, software architecture? Why has it taken so long to get to this point?
And why was it being defended so fanatically before anybody even bothered to study
the architectural suitability of this new fangled architecture, especially when an
existing loosely coupled, document oriented architecture
was already available? There’ll be lots of time to answer those questions in the
coming years, but it’s extremely disappointing to me that we weren’t able to ask them
in time to avoid learning a lesson the hard way.
Re Bloglines services; “The barrier to entry for this REST-done-right stuff is just so absurdly low, I just can’t see any other approach being competitive.”. Yup, and it would still have been even if it were strictly RESTful..
(
link) [
del.icio.us/distobj]
Dave Orchard thinks so.
But hold the phones! Along the way, we learn this;
Read operations using a generic protocol (ie GET) hits the 90/10 point
Woohoo! Preach it, brother!
But you knew it wasn’t going to end there…8-) He goes on to defend
the need for service-specific write interfaces with an example.
Without getting into the details of that example since they’re reasonably
complex, I certainly agree that one can, without too much trouble, find
cases where uniform semantics are more trouble than they’re worth. But
so what? Did anybody ever doubt this was the case? I’ve
repeatedly
stated
(and long before too, though I can’t dig up any refs right now) that it was, including
mentioning that I’ve had to use non-uniform semantics on occasion.
I think the question David really needs to answer is this; do we need
specific write interface semantics like “orderBook”, “hirePerson”, “reserveFlight”,
etc..? I don’t think we do; I think POST suffices for all three.
Also, I wonder if Dave would like to augment his
architectural description of the SOA style
to include an interface constraint, even if it’s just for reads?