A couple of
interesting
developments
out of
Grand Central.
These guys have got it going on. Their network is largely state transfer based; not
REST, but not far from it either, and “like it” in the
right way.
At least they’ve (mostly) got past the API-centric view of the world espoused
by Web services proponents (yes, even for “document centric” Web services), despite paying
lip
service
to WSDL.
Plus they’ve got a
Semantic Web proponent
as
CTO.
Look for more good things from GC (and from third parties on their platform) in the coming months and years.
An HTTP proxy that determines when I’m POSTing weblog comments (or other
things, for that matter), and provides an RSS feed for them.
References;
Probably the most interesting thing that I learned about
RDF
on my last project was that resource typing (via the use of
rdf:type)
was over-rated. As a long time distributed objects weenie, I naturally
had this vision of resources (objects, if you will) with uniform
interfaces (what else?), but also with types orthogonal to those
interfaces (duh, since the interfaces are fixed) . You can’t
have an object without a type can you?
Then reality hit. Despite the fact that I had actually speced out a
type ontology for the project, and educated everybody about it,
almost none of our RDF processing software actually checked the rdf:type
triple! Apparently, if it
walked like a duck, and quacked like a duck,
then by golly, for all intents and purposes it was a duck! That
was very liberating. I knew the moment I realized this, what had happened;
I simply had overlooked what was important to the recipient of the documents, the data.
rdf:Description; not just a place holder for the lazy.
rdf:type; in many cases, YAGNI
I was wondering how long
that
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.
He writes;
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
screw up,
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
architectural constraints
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
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?
After much time and anguish, “application/soap+xml” is finally a done deal;
RFC 3902
Yet another service which opts for REST rather than SOA. Victory is mine! Muhahaha! 8-)
(
link) [
del.icio.us/distobj]