I recently thought about what to expect in a web framework that claims to have "REST support", and came up with a list of questions that one should ask to see whether such a claim is justified:

• Does the framework respect that an HTTP message does not only consist of a URI? I.e., is dispatch done at least based on the HTTP verb, the URI, the Content-type and Accept headers?
• Can I easily use the same business logic while returning different content types in the response?
• Is there support for checking for conditional requests?
• Are ETags calculated automatically if none are set by the backend logic?
• Can I (as a framework user) easily read all HTTP request headers?
• Can I easily set all HTTP response headers?
• Can I use custom HTTP verbs?
• Is it obvious and easy how to return correct status codes with responses, and does the framework use them correctly (if it does so at all)?

Update: Two aspects added due to feedback by Erik Mogensen and Mike Amundsen:

• Is there an easy way to produce links that "point back" resources identified by whatever means the framework exposes (such as some form of routing)?
• Are resources identified and requests dispatched to code by the full URI, or is there an artificial distinction between the path and query parameters?

Along the same lines, here are some questions where a "Yes" indicates that a framework doesn't do things the way they're supposed to be done:

• Are GET, POST and other requests to the same URI dispatched to the same business logic by default?
• Am I required to use "extensions" (e.g. ".xml", ".json") to get different representations of the same resource? (Supporting this optionally is OK.)
• Are there method names in the URI?

Finally, I wonder whether there's any justification for a web framework to support "REST services" as an addition instead of the default, but I'm reluctant to put this into the second list.

Suggestions for extending the list are welcome.