Passion * Technology * Ruthless Competence

Tuesday, June 05, 2007

« TechEd 2007 - Day Two Morning | Home | Afternoon Doughnuts 8 »

A REST Question

Since there appears to be at least a handful of RESTifarians among my readership, I'm just going to throw this half-formed thought / almost question out there. Maybe it's a FAQ, in which case I'd appreciate a pointer in the right direction.

My observations about REST are:

REST is a an "architectural style for distributed hypermedia systems".
REST "has been used to guide the design and development" of HTTP and URI.
Therefore REST as an architectural style is independent of HTTP and URI.
Yet, I get the feeling that the REST community would consider a solution that uses the REST architectural style but not HTTP and/or URI as "not RESTful".

Am I wrong in observation #4 above? If you're addressing resources by resource identifiers [aka URIs] but transferring those resource representations over a durable duplex protocol [aka not HTTP], are you still RESTing?

(Note, such a RESTful durable duplex protocol doesn't exist to my knowledge, though I would be very happy to be wrong about that. SSB does durable duplex, but it doesn't support URI style resource addressing. Granted, if I was going to build a durable duplex RESTful protocol, I would build on SSB - much the same way that HTTP builds on TCP. Though I am a huge fan of SSB, I'm specifically not suggesting that SSB is RESTful.)

Posted By Harry Pierson at 8:01 AM Pacific Daylight Time

Comments [6]

REST

Tuesday, June 05, 2007 10:01:27 AM (Pacific Standard Time, UTC-08:00)

This is the "Do you believe in evolution?" question for the faithful RESTafarians. I've had conversations about RESTful architectures in desktop applications that I felt were extremely useful. But without a doubt such a conversation would immediately be condemned by certain elements, probably combined with a suspicion that even asking the question is the first step in tricking / co-opting REST for your nefarious, Borg-like ends.

It's odd that an architectural style, the sort of thing that you might expect to see fruitfully discussed at PLoP, is so prone to dogma and passion. One wonders what people are so wound up about.

Larry O'Brien

Tuesday, June 05, 2007 10:39:20 AM (Pacific Standard Time, UTC-08:00)

The short answer to your question is that REST is not bound to HTTP.

To quote from Roy's dissertation:

"REST does not restrict communication to a particular protocol, but it does constrain the interface between components, and hence the scope of interaction and implementation assumptions that might otherwise be made between components ..."
http://www1.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_3_2
http://simplewebservices.org/index.php?title=Connector_View

There has, in fact, come up in conversation on [rest-discuss] very recently, see http://tech.groups.yahoo.com/group/rest-discuss/message/8781

Alan Dean

Tuesday, June 05, 2007 12:54:24 PM (Pacific Standard Time, UTC-08:00)

The author of REST himself is working on a non-HTTP protocol to better support REST. Search Google for "roy fielding waka". (There is only a tiny bit of information available...)

A discussion of building a REST-constrained system on top of SSB is perfectly legitimate discussion.

One caveat, (looking for link... looking for link...) because HTTP is so widely deployed and available (plus DNS) there is a huge immediate value in using "http:" based URIs. The simple benefit of an already deployed and free naming infrastructure is huge.

Ah! Found the link: Norman Walsh here: http://norman.walsh.name/2006/07/25/namesAndAddresses

John Heintz

Tuesday, June 05, 2007 1:14:56 PM (Pacific Standard Time, UTC-08:00)

The sample code that Alan points to is remarkably like something I have implemented recently to seperate the HTTP facing endpoints for REST from the actual implementation endpoints. This seperation / encapsulation allows me to do things like Transactions and program RESTful in-process too.

See a huge chunk of the benefit of REST comes from the formulation of a namespace of URI's. Why should you need to incur protocol costs to use a namespace? If that where the case it is kind of like saying all access to a HDD needs to be through network shares? (i.e. \\localhost\c$ instead of C:\)

And yes there does seem to be a fair bit of equating REST to HTTP going on recently, although typically, it must be said, by SOAP people just coming to grips with REST. I did a post on this very topic:

http://www.base4.net/Blog.aspx?ID=447

Alex James

Tuesday, June 05, 2007 1:28:24 PM (Pacific Standard Time, UTC-08:00)

I think you can separate REST from HTTP, but you ought to call it something other than "REST".

http://appside.blogspot.com/2007/06/rest-over-http.html

Erik Johnson

Tuesday, June 19, 2007 8:05:33 AM (Pacific Standard Time, UTC-08:00)

Clearly REST is not dependent upon HTTP and URI. When the Web was growing, another protocol could have been used for HTTP, and another content type than HTML. But the URI is key -- REST bounded the verbs (HTTP) and content types (MIME in Web world), but the nouns (URIs) are unbounded. It was the unboundedness of the URIs that was key. So -- sure you could replace the URIs with some other noun based approach -- but why?

John Tullis

Comments are closed.