On 3/7/06, David Binger wrote:
>
> On Mar 6, 2006, at 6:29 PM, Mike Orr wrote:
>
>
> they're bumping up against with CherryPy's built-in
>
> traversal, especially (1) restful URLs,
>
> I had to search around a bit to come up with a guess
> as to what is meant by "restful URLs.", so I'll share, in
> case it saves someone else some trouble.
> I think it means URLs that include components that
> identify individual stored objects.
Yes. It means that the record identifier comes before the action,
like in OO programming or a GUI menu. It also means that both are
encoded in the URL path rather than in query parameters, so that there
is a bookmarkable link to every record and every action. Examples:
/article/1234/ # Default action is view.
/article/1234/?print=1 # Options are allowed.
/article/1234/edit # Another action.
/diary/2006/03/06 # A 3-part record ID.
/incident/333/666/ # Show entry 666 of incident 333.
/incident/333/666/delete # Delete the entry.
/incident/333/add_entry # Add an entry
REST also implies defining the behavior for each HTTP method, and
denying requests that are inconsistent with the method. GET requests
should be repeatable (idempotent); they should not modify data
destructively. POST requests may modify data in a non-repeatable way.
PUT and DELETE should be used to replace or delete a static file (or
whatever the application considers a static resource), rather than
POST. I don't bother doing this because having an 'if' switch in
every callable is cumbersome, you can't count on browser support for
more than GET/POST, HTML doesn't expose all method everywhere (you
can't do non-GET hyperlinks), the method set isn't comprehensive, and
hiding destructive behavior behind POST forms is reasonably safe
enough because no hyperlink will contain the magic submit parameter.
This explain REST pretty well.
http://ajaxpatterns.org/RESTful_Service
Here's a RESTful application spec.
http://wiki.openstreetmap.org/index.php/REST
> In Q-speak, I guess that means that CherryPy does
> not support _q_lookup() traversal so well.
>
> Is that right?
CherryPy has what Quixote 2 expressly avoids: a built-in traversal
system that is supposedly perfect and can't (easily) be enhanced.
CherryPy's .default method does part of ._q_lookup: it matches an
otherwise-undefined URL component and returns a calculated response.
It can also match multiple sequential components like the "diary"
example above; thus overlapping with ._q_traverse. But traversal
stops at this method; you can't return a subdirectory to continue
traversal on. So the ID must be the *last* component(s) in the URL.
This makes it impossible to put the action after the ID unless the
..default method handles it all. This means the .default method needs
a big 'if' and call other methods, and it must accept a union of all
submethod arguments (fields) and pass them to the appropriate
submethods. This defeats the purpose of using CherryPy's traversal in
the first place (which automatically converts input fields to method
arguments), and also TurboGears' MVC magic of matching an action to a
template -- two of the main reasons one chooses TG.
But this also shows why I'm hesitant about Quixote. TG has people "on
staff" who understand REST and various other issues that pop up. For
instance, TG signs the auth cookie cryptographically to prevent
session hijack; I don't think Quixote does. This is another point in
TG's favor, and it comes from having more developers and a wider
variety of developers.
--
Mike Orr
(mso@oz.net address is semi-reliable)