Massive kudos to the WS-Addressing WG (in particular Dave Orchard) for agreeing to drop reference properties from the WS-Addressing specification!! This addresses the most major(!) concern I had with the specification, and leaves EPRs as a means for bundling a URI with some state; cookies meet XML, as it were.
This decision means that a by-the-book EPR will contain only a single resource-identifying data element; a URI. In other words, the WG is adopting the REST constraint of a single resource-identifying data element. More concretely, it means that Web services will actually be encouraging the use of URIs for identifying things, rather than the old practice of using them as dispatch points behind which countless resources were hidden. This is HUGE, because in my experience, once you’ve adopted URIs, the use of http URIs and therefore HTTP (buh bye protocol independence) just naturally follow due to the massive network effects of the Web. The use of “hypermedia as the engine of application state” is the next obvious constraint for adoption after that.
It’s possible that with this decision, Web services might have just stepped inside the Web’s Schwarzschild Radius. Stay tuned.
Another good article from Joe. I left a comment, but wanted to repost it here, since I think this is the most succinct description I’ve offered for explaining this critical point.
Nice job again Joe, but I think you’re a little (and I do mean *little* 8-) too rough on the existing service when you say “This is an RPC protocol trying to run over HTTP, and that misalignment is where the problems arise”. With the ListMyQueues and Read operations, putting them in a URI such that a GET returns the data *is* perfectly RESTful. This is because when in URI form, the effective operation – that which the client asks be done, and expects is done when receiving a successful response – is GET, not ListMyQueues.
It’s very(!) easy to misunderstand this point; the same point which is also, I believe, the principle impediment which prevents proponents of document oriented Web services from realizing that REST and the Web is what they’ve been trying to build.
I’ve been meaning to comment on these for a few weeks now, but it seems they’re making the rounds; hCard and hCalendar, HTML-encoded equivalents of the vCard and iCalendar specs. Check out this example hCard;
<span class="vcard"> <a href="http://tantek.com/"> <span class="n" style="display:none"> <!-- hide this from display with CSS --> <span class="Family-Name">Celik</span> <span class="Given-Name">Tantek</span> </span> <span class="fn">Tantek Celik</span> </a> </span>
Isn’t that freaking gorgeous? Let’s think about what constraints Tantek had to work within in order to produce that…
Beautiful! Web hackery at its best.
My only concern there is that without a URI to ground the class names (ala the same problem that XML namespaces were developed to address), you run the risk of confusing aggregators when names overlap. Perhaps the HTML profile element could be used, though associating the different profiles with specific class names would seem to require an HTML extension. Hmmm…
Anyhow, while I still believe that RDF will do the bulk of the heavy lifting for the Semantic Web in the long run, cool stuff like this and GRDDL will almost certainly help bootstrap it. Nice job.
Just stumbled upon a requirement to use REST for an EU software project;
System to system interoperability
Should use:
1. Roy Fielding's REST principles
Of course, in the same list they also mention “XML-RPC”, which cannot be used RESTfully (unlike SOAP, also in the list), but it’s a start. I’ve talked with folks from other government projects, and they wanted to use REST because they wanted to use the principles that made the Web work; they just weren’t exactly sure how to go about it.
I just discovered this article by David, apparently reprinted from an old weblog entry that I must have missed while at XML 2004. While I think I’ve said my piece on the topic of distributed objects vs. services, I wanted to respond to a couple of points in the article …
First, in the “State” section, Dave seems to make the mistake of confusing the different types of state (or at least the different locations of state). He says “Web resources that have a URI that are stateless and work with HTTP GET”, which is clearly not the case, since any resource that answers a GET request answers it with a representation of their state. When you hear “stateless” in the context of the Web architecture, it’s usually in reference to the protocol, not the resource … though you can, of course, have stateless resources if you want to.
I’m also not sure where he’s going with “on the Web” bit. It’s a cute phrase, but doesn’t seem to hold a lot of technical value.
But the next three paragraphs seem to mix the different types of state up willy-nilly such that you can’t really make sense of it. The major theme does seem to be about services with state, yet Dave makes reference to conversational/application state mechanisms such as cookies. Perhaps I’m missing something.
Next, in “Network knowledge”, he adds;
Effectively, Web services is remote method invokes but with knowledge of the remoteness.
I won’t disagree with that, but what the heck happened to document orientation?! That was the single most significant architectural advancement upon RPC that I’d seen come out of the Web services space since it began (at least from a service POV – clients were still as tightly coupled to the services they used as with RPC).
Inspired by Sowa’s Law of Standards, Jon Udell writes;
My guess is that we’ll see a de facto alternative to the W3C’s proposed semantic-web standards — Web Ontology Language and RDF
It could happen, but I don’t think so. I could definitely see a new XML serialization of RDF happening this way though, but RDF itself? It’s already very simple, and has even sacrificed some expressiveness (e.g. quads) in the name of maintaining that simplicity. I think that’s good and healthy, and I can’t imagine any other spec doing what it can and being any simpler, nor can I imagine being able to remove much from RDF and still have it be useful to a lot of people.
I haven’t done enough with OWL to have a strong feeling about it, but it doesn’t seem to add much in the way of (required) complexity AFAICT. For most people, it’s, just another RDF vocabulary.
In the same post he also references some words by Mike O’Dell on the problems with DNS. He comments;
I have no idea whether, or how, “distributed system technology” might finesse the governance issue. But it’s a challenge worth pondering.
Jon might be interested in what the zLabs (“z” for “decentralization”) are up to, in particular the zNS project (not much there yet, but the objective is clear at least).
For those of you not at XML 2004 last week, my new client is Justsystem, a mid sized (800 employee) consumer and enterprise software company based in Japan with a long history of successful product development. I’m working there part time, for at least the next several months, assisting them in making a new Web based compound document technology of theirs – xfy (pronounced “ecks-fi”) – a success. At the conference we announced the immediate availability of a technology preview (downloadable at that link), and the planned productization of the technology by mid 2005.
Since I first started exploring CORBA and OpenDoc integration back in 1995 or so, the vision of compound documents as both a general user interface model, as well as a largely universal data extensibility solution, has never strayed too far from my thoughts, nor my work. So when I was approached by the company in September, and introduced to xfy, the decision to help them was a total no-brainer. They totally get it.
Yes, it’s protocol independence theme month!
A gem of an exchange between the WSD and XMLP WGs.
It turns out that WSD wanted to be able to send a SOAP request via HTTP, but get the response back on some other channel. Fortunately, HTTP supports the 202 response code which permits the server to indicate exactly that. But unfortunately, the default SOAP 1.2 HTTP binding explicitly does not support 202. It actually used to, but the protocol-independence promoters had it removed because they feared, IIRC, that too much of HTTP was exposed to the application.
That made my week. 8-)
P.S. I hope to see lots of people out at XML 2004 next week. I drive down tomorrow. It’ll be my third road trip to D.C. in as many years; about 1000 kms each way, but a pleasure in my ride (though not as nice as a trip to Boston through Vermont and New Hampshire!). I’ll be announcing what I’ve been up to for the past little while too, with my latest client.