One of the claims often made against REST is that there's a lot of disagreement around it – that nobody can define whether something is RESTful or not.
I was reminded of this in a recent discussion, and I claim it's bullshit. The REST community actually very easily agrees on whether or not something is RESTful or not when it's put up for judgement. And the nice thing is that you can easily get very close to answering this yourself by looking at a Web API that claims to be "RESTful", and see if it really is using a few simple questions:
- Do the URIs actually identify resources, or do they encode operations?
- Are the HTTP verbs – GET, PUT, POST, DELETE – used according to their defined meaning? Or is e.g. a GET used for operations that have side effects a client would not want when following a link?
- Is hypermedia used, i.e. are there links in the representations that a client can follow?
- Are MIME types used to differentiate data types (in Accept and Content-type) headers?
- Are caching and conditional GET supported, i.e. are there appropriate cache control headers and ETags?
I claim that if you answer "yes" less than four times, your API is not RESTful. If you answer yes five times, you may still not have everything 100% correct – but you've built something that's very good compared to the average, and can have meaningful discussions about how to improve it even more.
(Check out these articles for more background: intro, rest anti-patterns.)