A fine description of why we prefer our URIs to be treated opaquely, in the context of a brain-dead spam-busting idea by a UK MP.

Because I needed to use this myself, but also because I wanted to flaunt the simplicity and expressiveness of RDF Forms, I whipped together a little spec …

URI Proxy provides a means of describing a RESTful service as being a “proxy” (well, kinda – read the spec) for other RESTful services. Composition via aggregation.

You’ve seen examples of services like this before; Google’s cache (example – though the full URI isn’t used, which sucks), Google’s translator (example) the Web archive (example), etc..

Apparently that needs to be reiterated. Interesting.

Computers->Programming->Internet->Web Services->REST. Neat.

David wrote an article on the BEA site, that, to its credit, confronts the issue (and IMO, mistaken assumption of so many); that the Web is for humans. He writes;

It turns out that humans are pretty darned smart. We can figure out a variety of interactions such as:

    * How to enter usernames and passwords into different pages
    * When to stop waiting for a page to return and resubmit the request
    * When timed out of a site, how to reenter data and get to the right pages
    * How to enter an e-mail address in a Web form, and then switch over to the e-mail client to view the resulting e-mail message
    * What ordering (or flow) of Web pages to go through to achieve a task

Dave’s correct that humans are pretty darned smart, and also when he later suggests that machine-to-machine integration requires additional standards because of this. But he’s mistaken if he believes (and I know he does 8-) that this requires disregarding REST’s uniform interface constraint. Allow me to run through that list to demonstrate …

How to enter usernames and passwords into different pages. For the specific case of user names & passwords, the Web already has a standard for that. For the more general case of entering any data, I agree that a standard is missing. That’s why I developed RDF Forms, but something like WIDL could also be used.

When to stop waiting for a page to return and resubmit the request. I can’t imagine a scenario where you’d need a standard for this. If the system were stateless, then time is immaterial. I would expect that what is most important would be that when you do resubmit, that the expectation about invocation semantics are explicit, e.g. “once and only once”, “idempotent”, “safe”, etc… I agree that standardization is required here (though not as much as you might expect).

When timed out of a site, how to reenter data and get to the right pages. This sounds like a combination of the previous two, but I should also mention that RDF Forms uses “link metadata” (i.e. type information adorning a hyperlink, such as <PurchaseOrder rdf:about=”http://…”/>) that can be used by automata to “get to the right pages”.

How to enter an e-mail address in a Web form, and then switch over to the e-mail client to view the resulting e-mail message. Much like the first one above regarding data entry, but I’m not sure what “switch over to the e-mail client” means; surely my automata isn’t going to be using the Outlook GUI/app, it’ll be using some email client library or an HTTP proxy to an MTA.

What ordering (or flow) of Web pages to go through to achieve a task. That’s where “hypermedia as the engine of application state” comes in, as hypermedia is your application model. Link metadata is key here too; I talked about this in “Hypermedia Workflow”. But I do think some more standardization is required, specifically in the area of link metadata describing useful workflow abstractions such as rendezvous (none of the RESTful integration work I’ve done has required a workflow component other than vanilla hypermedia, so I can’t say with certainty what needs to be standardized).

Thanks to Dave for mentioning this, because it’s been such a long standing assumption that most Web services proponents would consider it unworthy of discussion.

I’ve known Graham for a few years, ever since I was at Nortel, working with a pre-release version of Objectspace Voyager (purchased by Recursion). He and I, and his team, had several interesting discussions about Voyager & CORBA, culminating in an attempted recruitment of yours truly (I couldn’t do the move).

Voyager was a Java framework which provided a smorgasbord of options for building distributed applications including agents, mobile agents, tuple spaces, and RPC (CORBA/RMI/DCOM/etc..). My fondest memory of it was when I used the Spaces package to prototype a workflow management system (with a constrained interface!! Who knew?! 8-) in about two days. To this day, I count that as one of my most aesthetically pleasing designs.

Shortly thereafter, I stumbled upon the work of a guy named Charles Axel Allen at a startup called WebMethods. That work was WIDL, and I used their WIDL toolkit to generate the Java stubs (IIRC) which I tied into my Voyager based workflow system. It’s hard to believe that it took me many more months to have my Web epiphany after flirting with something so similar to Web architecture in WIDL and Voyager Spaces. Live and learn.

Every successful large scale system (say, >1M nodes) ever deployed used a constrained interface.

Prove me wrong.

Update: somebody asked what I meant by “constrained interface”. Basically, I meant that it uses a coordination language.