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
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
in that thread appear to
with that). I believe this approach will ultimately fail, and that routing (ala
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

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;

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

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

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.