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:

  1. REST is a an “architectural style for distributed hypermedia systems“.
  2. REST “has been used to guide the design and development” of HTTP and URI.
  3. Therefore REST as an architectural style is independent of HTTP and URI.
  4. 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.)

This entry was posted by DevHawk on June 5, 2007. It was tagged REST.

Comments:

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.
This comment was posted by Larry O'Brien on June 05, 2007 at 11:01 AM.
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
This comment was posted by Alan Dean on June 05, 2007 at 11:39 AM.
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
This comment was posted by John Heintz on June 05, 2007 at 1:54 PM.
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. \localhostc$ 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
This comment was posted by Alex James on June 05, 2007 at 2:14 PM.
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
This comment was posted by Erik Johnson on June 05, 2007 at 2:28 PM.
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?
This comment was posted by John Tullis on June 19, 2007 at 9:05 AM.

Categories

Tags

Series

Disclaimer

The information in this weblog is provided "AS IS" with no warranties, and confers no rights. This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion. Inappropriate comments will be deleted at the authors discretion.