2004/04/19
That was really long-winded, wasn’t it? Ok, here’s the one-liner response to Jim;
Awesome, you’re doing state transfer. Now what’s wrong with REpresentational state transfer?
Add your comment
2004/04/16
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
and
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.
2004/04/15
2004/04/14
Yah, ditto. I wonder though, why anyone doesn’t seem to be asking the meta question; who put this Senator up to it?
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
2004/04/13
2004/04/11
Paper Airplane is a Mozilla plugin that empowers people to easily create collaborative communities, known as Paper Airplane Groups, without setting up servers or spending money. It does this by integrating a web server into the browser itself, including t
(link) [del.icio.us/distobj]
(link) [del.icio.us/distobj]
2004/04/10
Now, that’s cute.
I’ll get right to the point. He writes;
However, in the asynchronous case, imagine your Web Service is just like a letterbox. Letters happily fit into the letterbox and get processed by the back-end (i.e. you), but the 42″ plasma screen TV you ordered doesn’t fit into the letterbox – it doesn’t match the physical dimensions (as per its “schema”). This seems RESTful, no?
Absolutely.
The fact is that regular Web Services have a far more uniform interface than the REST style. I’ve laid down the challenge before, but you can’t get much more uniform than one (imaginary) verb, can you?
That’s really good to hear you say that Web services have uniform semantics. But it’s impossible for them to be more uniform than REST, because REST prescribes uniform interface semantics by definition. That verb you talk about – “processThis” – if it is indeed uniform, then it has semantics that are, for the purposes of this discussion, identical to HTTP POST. And you can build a perfectly RESTful system with just that one verb, and it would be accurately characterized as loosely coupled and based on document exchange. In fact, I just built one a couple of weeks ago like that for pumping three channels of seismographic data from a digitizer to a communications controller. It’s just that in my experience, for most applications, you can build a better RESTful system with additional verbs, in particular GET. For example, if there were any need to have my comms controller initiate the request for data, I’d use GET.
The other approach to requesting data is to, for example, submitting documents which describe query terms or templates to services which process them and return the results. And that also has its place in RESTful systems, including ones I’ve developed. But when you don’t have to query, e.g. when the endpoint identifier for the service/resource to which you POST that document identifies something stateful, then GET is perfect for retrieving that state (such as the aforementioned seismic data). And of course, URIs makes the perfect endpoint identifier because they’re easily identified and contain all the information you need to grab the data (at least the good ones do 8-), without needing to know how to do a query on them.
Anyhow, this discussion is super-duper encouraging from my POV. We’ve come a long way from early Web Services Architecture WG meetings where folks were claiming things like “GET, PUT, and POST are only good for browsers”, or “REST requires humans”. A long way, indeed.
2004/04/08
My one year contract with Nanometrics wraps up shortly, so I’m out looking for new and interesting things to work on. I’m particularly interested in any large scale (aka Internet scale) data integration projects. Any vertical would be fine too, though I’m most experienced with telecom and wireless. I’m also happy to work either with the companies that have the integration problems, or with an ISV developing software that targets those companies.
Getting back into standards work would be fun too.
My resume is available; I’ll be updating it later.