I've followed the whole REST and RESTful Web Services hype with some interest the last few years, and genuinely like several aspects of REST:
- You can't go wrong with a KISS approach to software development.
- Most everybody is familiar with how the Web works, so exploiting that familiarity makes a lot of sense.
- The HTTP underpinnings of REST make it very well supported by a multitude of tools.
- By leveraging HTTP, REST has excellent support for intermediaries (i.e. proxies and caches) and all the cool things they can bring to the table.
On the other hand, I also have some reservations about the whole REST thing, and Mark Nottingham touched on several of these topics in his talk:
- As always, there is a lot of dogma to go around, and everybody has his own flavour. Is using this or that HTTP method in a particular way RESTful? Mark, who's obviously intimately familiar with HTTP, seems to have a much more pragmatic view on how you can or should use HTTP (i.e. listen to his comments on POST at the very end of the talk).
- HTTP is deceptively simple. The spec is BIG, and full of ambiguities. The entire first part of Mark's talk deals with this, and I would argue that most people (me included) only have a superficial familiarity with HTTP.
- Another thing I dislike about REST is that it's not generally applicable. For instance, suppose you're developing a search service, like Google (a typical text-book RESTful Web Service example). Most everybody in the REST community agrees that you should use HTTP GET for the search and encode the query in the URI: http://www.google.be/search?q=jellyfish. Imagine a similar search service that allows you to search for images that look like a given image. Logically this is completely in-line with the simple search service, but because of technical limitations of HTTP GET you're forced to implement this in a different way (WS-* is more consistently applicable this way).
For me, it's all about sane software engineering. If you have a well designed service, using established standards and conventions where relevant, people are going to be able to use your service without much problems. Things like REST and WS-* all have there place as tools in a developers toolbox, and it's up to us developers to make informed decisions on when to use what to build the best possible software we can.
Hi, Erwin.
ReplyDeleteI too was somewhat skeptical of REST when I first began looking into it. But over time I've come to value the consistency and composability of services built using the approach.
With regard to searches which encode the query values as part of the URL versus using an entity body, what's the big deal? It's quite simple to send something like an image as an entity body in a GET request if you want to send the image for comparison as part of the request. Of course, if there is a URL for the image, you can just send that as part of the query and let the service retrieve the image as needed (possibly leveraging cached search results -- since you've now used an addressable entity and a connected style of service implementation).
Can you please clarify?
Thanks,
Brian Gilstrap
Brian,
ReplyDeleteI agree that a URI like "http://www.google.be/search?q=jellyfish" is perfectly fine (that's also how I would design such a functionality), and indeed, you could send an entity body along in a GET request to implement the 'image search' similarly. However, an entity body in a GET request currently has technical issues (even at the HTTP level if I follow Mark's comments correctly) and you can't use this technique in a normal web application because browsers don't support it.
That was mainly the point I wanted to make regarding 'general applicability': the HTTP methods were designed for particular use cases and the web uses them in a specific (contrained) way. When designing your own web service, you pretty soon end up with situations that logically fit perfectly with a particular HTTP method, but you can't implement it that way because of technical issues.
RPC style web services with overloaded POST push this problem into the application design domain: you can POST pretty much everything and it's up to the application developers to design the payload representations appropriately. As such, your service design is less likely to be influenced by technical issues.
If the image that acts as the search criteria is an addressable resource, like you mention, then REST of course really starts to shine.
Erwin
Erwin,
ReplyDeleteI get you now. I agree that browsers and HTTP 4.0 are barriers to adopting REST when you are focusing on traditional browser-based applications. If you're willing to use a little (or a lot of) Ajax then this issue disappears. And the issue doesn't exist for applications that aren't browser-based.
My biggest dilemma had been how to test these sorts of applications. But between curl (for hand-driven, exploratory testing -- possibly scripted for unit testing) and the Jersey client API, that problem is gone.
I should say that I haven't yet had time to watch Mark's talk. I'm not sure what technical issues he might be referring to other than the fact that browsers don't like to send entity bodies (and don't give you a means to do so) when doing a GET. Were there other technical limitations he cited? (I've not run into them).
All the best,
Brian