Web Things, by Mark Baker

I’m glad I’m a Canadian, so I can laugh this stuff off. But ouch!
(link) [del.icio.us/distobj]

A sad, sad day for distributed computing on the Internet. P-)
(link) [del.icio.us/distobj]

“What is the least understood thing in computing that if only it were understood, everything would change?” Easy; the Web.
(link) [del.icio.us/distobj]

Since when did Zvon start including spam links in their RFC pages (see the bottom of the page)? At least they’re not hidden ala WordPress & Syndic8, but shame on them.
(link) [del.icio.us/distobj]

I’ve finally revised my RDF Forms specification.

The big changes were to simplify it by getting rid of the SOAP-specific action/intent support (so much for that olive branch 8-), adding support for PUT via the Settable abstraction, and adding a shortcut style of form whereby the method is explicitly declared (though there’s issues with this, as an Ed Note points out).

I also removed a closed world assumption by replacing the use of “indexedBy” with “parameterizedWith” for non-Indexable forms. Darn, those are hard to find sometimes.

The topic of service granularity popped up a couple of times a few weeks ago. And though I’m a bit late to the discussion, I’d like to contribute because I think there’s an important point here which is related to REST, as James anticipated, but didn’t expand upon – apparently he chose to play his analyst’s “Get out of real work” card 8-)

I’ve often been heard to say that I think that large scale architectural styles require interface constraints, but I’ve never, AFAIK, related that to granularity. So here goes …

In my Service Oriented Web presentation from, I used the generalization argument to describe the uniform interface;

getRealTimeStockQuote: not uniform ...
getStockQuote: not uniform ...
getQuote: not uniform ...
GET: uniform

Web services & SOA currently offer no guidance for – aka, provide no constraints upon – operation semantics; all of the above are A-OK, and no one should be preferred over the others. On the other hand, REST says only the last one – GET – is viable because of its extreme generality.

But what does this have to do with granularity?

Well, if you’ve got a single service with, say, three API calls (also taken from the SOW presentation, via StrikeIron);

GetNewHomeBuyers
CountNewHomeBuyers
GetRemainingHits

… then, in generalizing those, you end up with three operations that all have to be GET (since all are “questions”), which you obviously can’t have. So what to do? You use three services, of course! Isn’t that a lot easier than the complexity that ensues when the architectural style punts on the hard decisions?

Note that those three services are, IMO, at the perfect level of granularity; data sources, identified by a single, universally recognizable, compact string, requiring that client use nothing more than existing infrastructure to access the data held by the services (assuming the string begins “http:”, of course). Simple. Minimal cost. And pervasive to boot.

Gotta love the Web.

P.S. “sinks” in the title of this post refers to what you get when you generalize non-idempotent mutating operations like “orderBook”, “printDocument”, etc… They generalize down to POST instead of GET, and therefore each become a service to which one can chuck data; hence they become “sinks”.

“It seems that if a web service can, in any reasonable way, be treated as a repository of files, someone, somewhere will find a way to turn the web service into a file system.” Webize it!
(link) [del.icio.us/distobj]

“The labels’ insistence on trying to control what people can do with the music they buy has gotten them into this mess, and it will take a reversal of that position to get them out.” Wouldn’t that be cool?
(link) [del.icio.us/distobj]

All your media types are belong to us!
(link) [del.icio.us/distobj]

Yes, I am having some Debian packaging troubles, but no, it’s really not that bad thanks.