A few blog posts reverberating in my mind:
I just ran across a post by Joe Gregorio today, where he's comparing WS-* RPC vs. REST, specifically talking about the fact that WS-* RPC only uses the POST request method of HTTP:
"That POST of a generic media type gives no indication if the request is safe, or idempotent, nor is there any indication of the cachability of the response."
I also just read this morning a post by Leonard Richardson on Amazon's new FPS service, commenting on the 'REST'y ness of the service:
"its 'REST' interface is about as RESTful as Flickr's and del.icio.us's 'REST' interfaces"
Note, the Flickr and del.icio.us aren't considered terribly RESTy. :-)
Joe notes a handful of things that "just using POST in HTTP" breaks. Leonard notes that FPS isn't truly RESTy, but is in fact just as non-RESTy as two other fairly popular services.
And I'm left wondering: do we really need to do everything in pure REST?
Perhaps we can identify a small set of characteristics that get us most of the benefits of REST, that would be easier to implement than going 'full' REST. And just focus on those. Because apparently, it's hard to do full REST. Or to be even more pessimistic, perhaps there are disadvantages to using REST. Why would Amazon and Yahoo not use REST?
Most of the obvious advantages with REST revolve around the GET verb. Make sure you only put safe, idempotent actions behind the logic of your GET processing. Use ETags, or even better, cache directives, in your HTTP responses on the GETs to allow clients to intelligently cache things.
What else? Are there really other benefits? If there are, why are people still not jumping on the RESTy bandwagon?
Here's my thought on the lack of adoption of REST: it's complicated for anything but the GETs. Namely, the mutating verbs POST, PUT, and DELETE. Not technically, but semantically. Check the rest-discuss mailing list sometime. I've been having conversations with folks here recently regarding some of the semantics of 'updates' as well; ask 5 people their thoughts, you'll get 10 different answers.
Martin Nally had told me a few months ago that he thought people should be able to do 90-95% of their services in a RESTy style, and for those interfaces that didn't fit the REST mold, you could do 'em in non-RESTy style (ie, some kind of RPC-ish non-GET mutation operation), but it should cost you a $1000. I think I'm ready to lower the price to $100.
Updated on 2007/08/03 to fix a syntax error in the image element.
No comments:
Post a Comment