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”.
Yes, I am having some Debian packaging troubles, but no, it’s really not that bad thanks.