I was wondering how long
would take. 8-)
And here I was thinking
2004 was supposed to be it. Or
was that 2003?
It’s hard to keep track, except that I’ve noticed that it always seems to be
next year… at least until folks just get tired of waiting.
Yet another good thing about the Web; it already had its
“year”, ten years ago.
I don’t think people are embracing REST services because of architectural purity (the rest of the Web isn’t pure REST, so I don’t know why this would be). Rather, they embrace it because it’s easier in a lot of cases. There is no reason that SOAP couldn’t be the same, except that toolkits hide raw XML and you have to know how to get it.
To the first point, yes, certainly, they embrace it because it’s simpler and easier.
Absolutely. As we’ve seen, they often
but even then it’s very often preferable to SOA.
To the second point, there actually is a critical reason (in addition to
the “hide the XML” problem) why SOA/WS cannot be as simple as REST; that the
which induce the bulk of the simplicity
in REST (uniform interface, self-description), are eschewed by SOA/WS. Isn’t it ironic
that their raison d’etre – service specific interfaces – is the reason they will fail
to see widespread deployment? I think so. 8-)
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
But as a meta point, isn’t it nice how clear things become when using the language of
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..
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
(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?
After much time and anguish, “application/soap+xml” is finally a done deal;
Yet another service which opts for REST rather than SOA. Victory is mine! Muhahaha! 8-)
‘I always thought that REST should stand for “really easy services, today”‘
Via the Now Economy, a good
of the past few days’ goings-on regarding the WS-* mess backlash, with lots o’ links.
Amen. Stick a fork in WS-*, because as Simon says, Web Services are receding
Wow, the shit’s really hitting the fan this time, isn’t it?
Go go stop energy!
The latest entrant is a surprise (to me at least);
Though Simon and I may not like the stack for different reasons, any way you look
at it, WS-* seems to be on its last legs.
Onwards and upwards to true loosely coupled, document exchanged based
distributed services! You know, the World Wide Web.