Monthly Archives: July 2002

From REST to URIs, the Semantic Web, RDF, and FOAF

Good grief. Anyway, this exploration is certainly opening more doors than it’s closing. Actually, that’s not quite right. It’s showing me new doors that I choose to go through. This one had FOAF written on it in shiny brass letters.

FOAF is a project under the RDFWeb umbrella, and is an effort to build a vocabulary for expressing relationships between and facts about things on the interweb. As with REST, a key axiom (hrm, is that verging on the tautalogical?) is that URIs are very important, in uniquely identifying resources. There’s a good introductory article by Edd Dumbill on FOAF.

I’ve had a first hash at a FOAF file to describe me, and it’s here. In the growing fury of social network construction and subsequent mining, this could be interesting. Hey, and it doesn’t have to stop there… Under the influence of a small tumbler of Glenmorangie, I can half-imagine a situation where we have compound business documents and partners in an ERP system like SAP‘s R/3 exposed and linked (through the philosophical transparency of REST) to one another via their URIs, with those link relationships described in a FOAFy (RDFlike?) way.


The mist is clearing …

… but I’m not sure yet whether what’s being revealed is a bright sun, a dense forest, or more mist. In any case, it’s an interesting journey, and on the whole, enlightening.

I’m trying to understand more about REST. To that end, I’ve just written a little RESTful interface to RT (Request Tracker), in the form of an Apache mod_perl handler, so that I can create new and correspond on existing tickets via a simple interface that I can call from my other apps.

Creating a ticket:

POST /ticket

(queue, subject, email, and initial ticket query supplied in body)


201 Created
Location: /ticket/42

Corresponding on a ticket:

PUT /ticket/42

(correspondence supplied in body, will be appended to the ticket history)


200 OK

(Hmm, perhaps that should that be PUT to /ticket/42/history, returning a 201 with a unique URI for that particular piece of correspondence, e.g. /ticket/42/history/20020715115442).

Getting info on a ticket:

GET /ticket/42
GET /ticket/42/basics
GET /ticket/42/history

200 OK

(ticket info)

I’m glad I had my copy of the excellent Writing Apache Modules with Perl and C close to hand, to remind me of things like $r->custom_response() and Apache::Constants->export(qw(HTTP_CREATED)).

The 80/20 of HTTP

I don’t know about you, but when I think of HTTP in action, I think of GET, POST, 200, 404, and 500. It seems that most of the HTTP work today (the 80%) is done in the context of these verbs and status codes (the 20%).

I just read a couple of Paul Prescod‘s papers: A Web-Centric Approach to State Transition and Reinventing Email using REST. They’re both interesting for many reasons, not least because they show some of the other 80% of HTTP in action.

Of course, some people might point out that the 80/20 ‘imbalance’ will remain so while protocols (mechanisms, encodings?) like SOAP encapsulate much of what HTTP has to offer. Hmm, it’s very difficult to write about REST and SOAP in non-loaded terms :-)

Anyway, if nothing else, in pondering the RESTian philosophy, I’ve been re-acquainted with the other 80% of HTTP, and those things like URIs that are closely linked.

Reflecting ‘ping’s with SOAP, Jabber, and Pubsub

Last month, Simon answered a cry for help from someone in the weblog community by creating blogToaster, a neat little IM-based app that alerts people about updates (coordinated through to weblogs that they’re interested in.

But the most intriguing thing was his Subscriber Interface for, the mechanism on which the blogToaster is based. It’s a SOAP-based frontend to the ‘Recently Changed Weblogs’ information. You tell the interface what weblog URLs you’re interested in and it gives you SOAPy pings at the URL you specified whenever they’re updated, taking care of the nasty polling business for you (and for everyone else, which is the whole point).

Inspired by this generous infrastructural act, I put together an experimental bit of code which reflects this mechanism out into Jabber plasma. It’s a pubsub concentrator that sits in front of Simon’s Subscriber Interface and allows any app that can send and receive simple Jabber packets to request and receive update pings via this subscriber interface, without all the tedious mucking about in HTTP and SOAP protocols [1] (with apologies to Douglas Adams).

The idea is that in the same way that the Jabber extensions for Danny O’Brien’s Panopticon gave the Panopticon server some breathing space by effectively diffusing the data to Jabber entities via a conference room, so this new mechanism abstracts the Subscriber Interface out and allows many subscribers to share one subscription connection. Publish/Subscribe. One publisher, many subscribers. The publisher, in this case the Subscriber Interface, only has to send out one SOAPy ping per updated weblog URL to reach potentially many notification recipients (subscribers).

So rather than reproduce a blogToaster-like mechanism, I thought I’d have a go at putting together a mini-infrastructure on top of which lots of different blogToaster-like mechanisms could be built.

The mechanism is running at JID ‘‘, and the packets are based on the Jabber PubSub JEP. It’s still alpha, and likely to fall over if you look at it the wrong way.

Here’s an example of how it works. You send a ‘subscribe’ packet, saying you want to be notified when DJ’s Weblog is updated:

SEND: <iq type='set' to=''>
        <query xmlns='pipetree:iq:pubsub'>
          <subscribe to=''/>

Then, whenever the weblog specified is updated, you get a packet pushed to you like this:

RECV: <iq type='set' from=''
        <query xmlns='pipetree:iq:pubsub'>
          <publish from=''>
            <name>DJ's Weblog</name>

The information in the name, url and timestamp tags (in the publish IQ) is taken directly from the weblog tag in the SOAP-enveloped callback message described at the bottom of the Subscriber Interface description page.

For now, as a bonus (or an immoral twisting of the Jabber pubsub packet philosophy, depending on how you look at it ;-) I’ve set up the mechanism to send you not only a publish IQ as shown above, but also a simple message packet with the same information, so that you can use your regular Jabber client to ‘process’ (read: see) the pings. So if you’re feeling brave, break out your Jabber debug app and send a few pubsub packets to If you’re not feeling so brave, you can wait until tomorrow – I’ve got a a few helper example apps that will hopefully make things clearer. In either case, remember this: if it works, it works because of the coolness of what Dave W built, the coolness of what Simon built, and the coolness that is ‘net based collaboration and open standards. Time for bed now.

[1] Ooh, talking of HTTP and SOAP protocols, I just read an interesting XML-SIG post by Paul Prescod which made some valid (but also nicely philosophical, IMHO) points towards the end of the mail regarding whether SOAP is actually a protocol (as opposed to, say, an encoding), and how much, despite its ‘independence’ of transport, it depends upon its binding to HTTP, as much as any protocol depends on its binding to a lower-level transport. But I digress..