So apparently “processThis” is now – get this – an imaginary method. 8-)

But I know exactly what Jim’s talking about. I just wouldn’t use the word “imaginary”, because it’s definitely there, aka “in effect”, it’s just implicit; consider that a fault would mean “Sorry, there was a problem processing this”. It’s exactly like streaming video; video data arrives, it gets processed, moving pictures result. What we’re really talking about here (and I just noticed he had some more to say on the subject, in his brand .. new .. weblog! 8-) is the difference between these two types of messages;

Hello there


POST some-identifier HTTP/1.0
Content-Type: text/plain
[blank line]
Hello there

In order to make both messages semantically identical though, some additional work is required. First, the message has to arrive through a channel which has associated with it “processThis” semantics; you can’t just send it along on port 25 (the SMTP port) as is, and expect anybody to understand that you want them to process that data. So you really need a new port, which you have to obtain through IANA. To do that, you’ll need to describe to the IESG what the semantics of that port are, which you do by publishing an RFC which describes what “processThis” semantics are, and states that any data arriving on your special port will have those semantics. You’ll also need to state which spec controls the interpretation of the data, as there’s no (in my example, anyhow) way to indicate that as part of the message, ala the role that Content-Type plays in the HTTP message. Phew! That’s a whole lot of semantics to attach to a single port number!

Which brings me to the advantages of doing all that stuff as part of the message. First, it’s far more extensible. With the former example, if either the semantics of the interaction, or the semantics of the data processing need to change. For example, what if you want to query or store data, rather than just having it processed? You’re SOL.

Practically all large scale systems nowadays make their semantics explicit on-the-wire rather than implicit, in large part for reasons such as those I gave. Even some AV streaming protocols like RTSP do too.

But my intent here isn’t to critique this approach. The extensibility problem is a relatively minor problem compared to the enormous win of using a uniform semantic. What I’m really doing here is trying to describe how REST and Web architecture are an extension on top of this simple but powerful form of interaction. Or in other words, you could build a large scale system with the approach that Jim and Savas advocate, and it would be hugely wonderful thing. But it would still just be a subset of the Web in terms of size and functionality. Let me ask a couple of leading questions that might help drive home that point …

First, how do you address your messages? Just to a remote IP/port? I think you’d agree that you’d need a standard way to address remote data processors, no? And that address would have to be part of the message, otherwise you’re stuck with a single processor per IP/port tuple. So now, you’ve got a means of identifying anything which can reasonably be modelled as something that accepts data. For example, you could have an identifier for me, and if you sent your data to my identifier, perhaps the content would appear on my Blackberry, or arrive on my fax machine or some-such. It would be very much like email.

So now, you have these wonderful standardized identifiers, which you know identify things, many of which have some state associated with them (like myself 8-). Wouldn’t it be useful to have a uniform means of requesting that state be serialized as a response message? That’s the role that GET plays in Web architecture. And the URI is, of course, the standardized identifier.

Can you see why I’m so excited? You (Jim) and Savas are so far ahead of the Web services crowd, that you’re actually describing something that’s as useful as email (I’m not being facetious, that’s really a wonderful thing)! But the Web is just a baby step away.