Is it truly REST?
Madireddy Samuel Vijaykumar
Matt Goodall
> Hi,
> I have gone this this
> blog http://www.innoq.com/blog/st/2010/07/rest_litmus_test_for_web_frame.html
> and feel that some one should answer these against what RESTish does.
> Sam
Hi Sam,
That's a great blog post, isn't it. I read it last week and have
bookmarked it as a nice, simple list to check against. So, here goes
...
* 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?
Yes. Dispatch is currently based on URI, method, content type and accept.
* Can I easily use the same business logic while returning different
content types in the response?
Yes, sort of. restish will call a Resource method, the rest is up to
you. However, it would sometimes be nice if there was something to
automatically render responses from a common data structure.
* Is there support for checking for conditional requests?
No, I'm missing built-in support for caching right now. Something I've
been meaning to address for a long time now!
* Are ETags calculated automatically if none are set by the backend logic?
No, see above comment about caching. However, is this really that
useful? I think handling ETags effectively is quite application
dependent and not necessarily directly related to how the
application's data got serialized to some representation. Perhaps
automatic ETags is a reasonable fallback though.
* Can I (as a framework user) easily read all HTTP request headers?
Yes. The request is explicitly passed to the resource's methods.
* Can I easily set all HTTP response headers?
Yes. You can return an http.Response and many of the http response
helpers (http.ok, http.see_other, etc) accept headers too.
* Can I use custom HTTP verbs?
Yes. A restish resource is simply something callable that accepts a
request as a positional arg, so you can check the request method
yourself if you want. You can also define and use your own
@resource.GET -style decorators (there's deliberately nothing special
about them).
* 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)?
Yes and yes. The http response helpers (http.ok, http.see_other, etc)
exist to guide you in constructing good responses. restish itself
tries to construct good responses for errors, e.g. method not allowed,
not acceptable, etc.
* 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)?
This is a tricky one. restish doesn't implement routing in the way
many frameworks do as I've often found them too simplistic and static
(very much personal taste, this one). As a result a Resource doesn't
have a single URL and can be used in multiple places in the resource
hierarchy is you want.
To achieve something similar, I define application-fixed URLs in a
module and reference those from application code, see
restish.contrib.appurl.
Yoan Blanc experimented with resources with URLs. Perhaps he can add
to this answer?
* Are resources identified and requests dispatched to code by the full
URI, or is there an artificial distinction between the path and query
parameters?
Not quite sure I understand the "artificial distinction" point.
restish locates a resource based on the URI path; the query params are
passed to the resource as part of the request. I think this is correct
behaviour.
(Note: the following are supposed to be anwered, "No".)
* Are GET, POST and other requests to the same URI dispatched to the
same business logic by default?
No. Dispatched to the same resource, but different methods.
* Am I required to use "extensions" (e.g. ".xml", ".json") to get
different representations of the same resource? (Supporting this
optionally is OK.)
No, restish negotiates based on the Accept header. I'd then use some
WSGI "middleware" to map extensions to Accept header.
* Are there method names in the URI?
No, not unless you put them there ;-)
Hope these answers help, let me know what you think.
Apart from missing caching and a different "philosophy" on routing I
think restish does quite well against this list. However, as always,
there's plenty that could be improved!
- Matt