Web Things, by Mark Baker

Scott Lawrence joins the ranks of HTTP gurus looking for work. If you need somebody who understands HTTP (not sure if he groks REST though), you couldn’t do much better than Scott.

I just sent this message (with this followup) to the Web Services Description WG to try and get first class support for application protocols (rather than requiring that they be treated as transport protocols) into WSDL. Let’s see how that goes.

Sean McGrath with another fine article about REST.

I had also been using the grammatical metaphor recently in some off-line discussions, to try and explain visibility. The one interesting nugget that emerged from that exercise, was that application protocol headers are adverbs, as they modify the verb (method). So a GET with an If-Modified-Since header, is a “conditional GET”, but – and to tie this back to visibility – it’s still a GET, the same way that “eat quickly” still describes the action of eating, whether or not you know what “quickly” means.

Yes, it’s a slow news day. 8-)

Like many other discussions (though perhaps much faster than most 8-), Simon gets to the heart of the matter;

[…] but at that level so is SOAP, its always HTTP POSTs[…]

While trying not to sound too much like a broken record, there is just one “level” here, the application layer; HTTP methods are application methods. POST is as much an application method as doSearch(). When you use HTTP/REST, you as a developer aren’t normally defining any methods, you’re just filling in the arguments to the methods that HTTP provides. That’s what “interface” in the uniform interface constraint is referring to; the API.

Simon Fell says that he has trouble understanding some of my arguments, in particular this one where I attempt to outline the value of pipe-and-filter style composition over a choreographed solution. Let me elaborate here then.

It’s long been recognized that composition of components is simpler and more tractable when those components share an interface, if only because you can reuse glue code. For example, the code written to late-bind the Unix commands “ls” and “more” into “ls | more”, is split between the stdout-using code of “ls”, the stdin-using code of “more”, and the binding code in the shell that processes “|”. All of that code is reusable in more contexts than piping “ls” into “more”.

My examples were meant to show the strong similarities between Unix style composition, and REST style composition. REST, by itself, supports two styles that I’m familiar with, which I described there; composition-by-URI, and intermediary routing. The latter is more powerful and flexible, but the former easier to use, though at the cost of not being standardized (not that it should …).

From what I can tell, the Web services answer for composition lies with choreography (and some in that thread appear to agree with that). I believe this approach will ultimately fail, and that routing (ala WS-Routing, PEP, Idokorro, KnowNow) will prevail.

James Strachan asks that if the method doesn’t go in the SOAP envelope, could it go in the URI or an HTTP header? My answer would be “No”, that in order to gain the benefits of REST, the only method you need should be the one in the HTTP request line, such as GET/PUT/POST. That’s not to say more methods can’t be defined, only that they should all have uniform semantics, and that when using HTTP, they should be HTTP methods.

Does that explain why HTTP is an application protocol, and not a transport protocol?

More tail-chasing going on over at the W3C with the chartering of the Web Services Choreography WG. I’m really disappointed that Tim didn’t take this opportunity to speak his mind about the mistakes being made with Web services, especially considering that this working group exists to replace the hypermedia application model, which is pretty darned fundamental to Web architecture.

I guess he knows what he’s doing though. Perhaps he feels he can contain Web services, and prevent them from preventing him from leading the Web to its full potential. I did think that the initial move to accept them into the W3C was an excellent one, as there, they may actually be fixed enough to earn the right to call themselves Web services. Unfortunately, nobody seems to be officially assigned to the task to doing just that, though Hugo and David try to keep things in check, what most people know to be Web services (i.e. putting the method name in the SOAP envelope) is a fundamentally broken style for the Internet, which is a big issue for them to tackle, especially given the mostly neutral positions they’re expected to hold as team contacts (not officially, but in practice it’s hard for them to hold strong opinions). That’s why I’ve been doing it.

Sam Ruby implements the RSS Trackback module in his RSS 2.0 feed. It’s implemented by simply including a “trackback:ping” qualified URI in the item. For the item that corresponded to his announcement of support, the URI is;

http://www.intertwingly.net/blog/1105.tb

So being the Web-head that I am, I invoked GET on it. Here’s what I saw;

<?xml version="1.0" ? >
<response>
<error>1</error>
<message<excerpt not found</message>
/<response>

I note that Paul, Ben, and Mena had written about what could be returned, which is bang on from my POV, though you could also include the number of received pings in there, which could be useful, and make a nice link from the human-readable blog.

Just thinking out loud; I’m not trying to put more work on Sam’s plate 8-).

A nice surprise turned up in my IETF mailbox this yesterday, Applying WebDAV to Network Configuration Management Problems.

This memo examines the potential of using WWW Distributed Authoring and Versioning (WebDAV) technologies to address the problems of network configuration management. It reviews requirements and issues that have been identified in IETF network configuration management and operator requirements discussions, matching these requirements and issues with various WebDAV facilities. It concludes by identifying areas for further exploration.

Bravo. We need more of this kind of reuse-friendly work.

Which reminds me … I forgot to mention that an Internet Draft that I wrote with Dan Connolly on a related topic (reuse, in the context of registries) was published too.

I awoke this morning to a dead Wifi network in my house. Oh joy. Close to three years of pure bliss of 802.11b in the whole house, then nothing. A quick investigation turned up an almost identical report explaining the state of my base station. It looks like it’s totally dead. In the mean time, I’m now shackled to my basement PC until this gets fixed. At least I’ve got my new monitor to keep me comfy there.