Web Things, by Mark Baker

The term “zero install” is commonly used to refer to the ability to deploy new applications without upgrading client software which has to deal with it. In an important sense, the entire World Wide Web project, including the Semantic Web, can be viewed as an attempt to bring this modus operandi to distributed computing in the large, including to browsers (and the humans using them), but also to automata. URIs, HTTP, and RDF, have all been designed with this objective in mind.

Via Dave Beckett, we see Timo Hannay explaining one of the key advantages of RDF;

I’m currently involved in a project that involves aggregating and querying a lot of RSS data. The only extension modules we can deal with in a fully generic way are the RDF-types ones designed to work with RSS 1.0. To deal with RSS 2.0 modules (which don’t use an RDF structure, at least currently) we either have to manually add routines for each one to our code (a maintainability nightmare) or skip them all together (which means we lose data).

Would this architectural feature be useful to Web services? If so, what would it take for them to get it?

Ergh, I don’t know how I could have possibly missed this (get a blog, Steve!), but one of the distributed system people I most respect, Steve Vinoski, wrote a great article on REST and Web services (PDF) a year ago that should IMO, be mandatory reading for Web services folk.

I have one (rhetorical) question for him though. Steve writes;

These verbs form a generic application interface that can be applied in practice to a broad range of distributed applications despite the fact that it was originally designed for hypermedia systems.

So is it that HTTP can be used for applications other than hypermedia, or is that hypermedia is perhaps an extremely generic application model?

As an after-thought to my last response to Doug, I thought I’d just say a quick word about “documents”, which Doug likes to talk about.

A document is state (the S in REST). Look in any file folder (the kind in the filing cabinet), document storage system, archived tape, or heck, any file system, and you will find chunks of state. What you won’t see in any of these are “methods”. If you encapsulate the state within a “method” wrapper, then what you have is no longer a document, because it carries with it intent; state does not.

If document transfer is your objective, then REST is what you need (and maybe some more constraints on top).

Doug responds, in reference to using URIs;

This implies that the document is associated with (tightly coupled to) a fixed location as specified in the URI.

Not at all. Are you aware that the machine that you’re grabbing my blog from relocated up the street five months ago? In the odd chance that you were, did any of your links to my blog have to change, or were you or any other linker to my site impacted in any way? No, of course not. A http URI is not location dependent if it uses a DNS name (as opposed to an IP address), because a DNS name can map to multiple IP addresses over time.

He also writes;

You can’t send email to me using an HTTP GET or[sic] POST to my desktop PC because it may be turned off.

That’s not true. You appear to be looking at REST through from the point of view of a browser. It would help to look *past* the browser, to state transfer (aka document tranfer). You could have a HTTP gateway sitting on some server someplace, which I POST emails too. When you boot up your laptop, you’d connect to the server, and invoke GET to retrieve those emails. That’s perfectly RESTful.

For those not familiar with it, the W3C’s www-archive public email archive is a great place to peruse some behind-the-scenes activities which are public, but not announced. It’s also home to a lot of Tim and Dan‘s discussions which are redirected from other mailing lists. Well worth following.

While checking it out yesterday, I found this gem from Roy Fielding on ambiguity in identification and the need to confront “secondary semantics” that result from that ambiguity.

In 5 or 10 years, people are going to look back on these archives (and perhaps the RESTful ones on www-ws-arch 8-), and realize that these were actually some of the most advanced and important du jour topics in large scale distributed systems research and practice … a far cry from the esoterica that it must seem to Web services proponents. I’m humbled when I realize how fortunate I am to have understood this early enough (only five years late, relative to 1993 when I first learned of the Web! 8-) to be able to make a contribution to the World Wide Web project, if only through education and evangelizing (hey, somebody has to do it!). I’m confident it will be my professional legacy.

Doug Kaye responds. It seems we did miscommunicate. I like to tweak my terminology on occasion, to try to blur distinctions for my readers that I believe are artificial, such as that between objects and resources. It came back to bite me this time it seems. I’ll be more careful in the future.

Doug writes;

I continue to believe that dynamic documents, such as those which evolve during a complex business process, are best communicated through non-REST style interfaces.

Which is weird, because I’d say that is what REST does best. A URI is just an identifier. I could use one to identify some instance of a business process, and at any point, anybody with that URI could invoke GET to retrieve a document which represented the state of the process. As the process makes progress (in any direction 8-), subsequent GETs will return different results representing the current state. I’m not sure how else to handle viewing dynamic processes, other than transferring some mobile agent pickled with its state, and then prodding the agent for the info, but I don’t think Doug’s talking about that. Hmm…

If you’re following the TAG discussion regarding the httpRange-14 issue, you’re probably aware of the two (at least I think and hope it’s just two) positions about this; either http URIs without a fragment identifier can identify anything, or they can identify “documents”, aka “information resources”, aka “cyc:ConceptualWork”s. I’m unapologetically in the “anything” camp.

As this debate has flared up every few months in some forum for the past several years, I thought a bit about some of the implications of my position, and whether there was anything there that hadn’t yet been said. I came up with a couple.

First, in general, who’s to say that any string can’t identify any thing? My name is “Mark”, and that name identifies me; not globally uniquely of course, but I don’t think anybody would claim that it wasn’t an identifier. So as an identifier, it would be really nice to be able to ask a HTTP proxy for a representation of me using that identifier, e.g.

GET Mark HTTP/1.0
Accept: image/jpeg, text/html

The only reason that isn’t possible, of course, is that HTTP accepts URIs on the request line, not arbitrary words. This is because URIs have more structure than your typical word such that a machine can extract out all the information it needs in order to retrieve a representation via late binding.

So assuming we all agree that “Mark” is an identifier for me, then we should all expect that the request above would return a representation of me. Why then, should our model of how this works be any different if I use “http://www.markbaker.ca” as the identifier for me in that request? My name is not “Mark#him”.

Second, it appears to me that adding a layer of indirection in the form of having a URI-with-no-frag identify “ConceptualWork about <subject>” rather than just having it identify the subject, removes the ability for state changes to be made. Consider my canonical “Web services are broken” example of a lightbulb; we have a URI that identifies the lightbulb, GET returns a representation of it to us, we toggle the “on/off” part of that representation, and then PUT it back to that same URI. In that example, there exists a perfectly reasonable expectation on the part of the client that PUT would change the state of the lightbulb (assuming the history of representations returned via GET was consistent with the URI identifying the bulb). Adopting the “http URIs identify cyc:ConceptualWorks” position would appear to force PUT to mean “write a new version of the ConceptualWork”, with no way to model actually changing the state of the lightbulb. Not good!

Note that this example was sort of similar to Roy’s POST/robot example, but using PUT instead of POST. I find PUT superior to POST for examples like this, because it’s easier for most people to understand what PUT does. But the principle is the same.

So to sum up, if it walks like a duck, and quacks like a duck, it’s probably not a ConceptualWork about a duck.

Sean points to a white paper he co-authored on “Service Oriented Integration”. Now, the content is almost all RESTfully delicious, but I can’t get past the terminology. It talks about the need for very generic, coarse grained interfaces (yah!), document flow, etc.., but uses the term “Service Oriented” all over the place too. I know it’s technically a very generic term, but it’s extremely commonly understood to mean application-specific interfaces. IMO, this takes away from the value of the paper, as it doesn’t provide a sufficient “jolt” to the reader proficient and/or familiar with what “Service Oriented Architectures” are, such that they’d recognize the major point the paper is trying to communicate.

But maybe it’s just me.

I was going to write more about services vs. resources here, but it’s late and I’m tired. Perhaps later this week, once I finish the DOA 2003 reviews (eight of them, ick!).

I just found this wonderfully written description, by Joseph Reagle, of the value of both pragmatic and principled approaches to group work.

Often there are debates about the means used towards common ends: are we better served by being pragmatic or principled? I think both are useful positions. For example, some individuals might choose to be uncompromising, to stand far out on the edge of the lever. In their singular position they don’t weigh much, but their extremity does increase the torque by reminding us of the principle at stake. Others might devote themselves to the process and institutions of consensus. The fulcrum itself is unwieldy and difficult to move, but if one can shift it, that too can have a profound effect on the ultimate balance.

I’ve always felt this. I’ve experienced a couple of occasions in my standards work, where a principle needed to be relaxed in order for concensus to be reached so that the work could make any progress. I’m happy to disregard principles when (and only when) I feel that the value of getting something done, however flawed, is higher than the value contributed by that principle. But, that’s quite often not the case. My stance against the current “SOA” approach to Web services, which rejects pretty much all the important principles that made the Web such a success, is an example of that.

Back in May, I was worried that my prediction that XMethods would list less than 400 available services may not come true, as 358 services were listed back then. I just checked the number now, and it was down to 342. I’m not sure why the dip – I’ll have to ask Tony – but I’m breathing a little bit easier. 8-)

I wonder, if Web services are going to be such a big thing, then surely at some point there’ll have to be millions of them around, right? If so, what do folks think it will it take to get there (other than tens of thousands of years 8-)?