On Aug 22, 11:58 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 22, 2008 at 6:43 PM, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
>
> > I'll admit at the forefront, I'm not a fan of the extreme
> > 'restification' of the web the way the rails evangelists and followers
> > have pushed for, or the 'restful web services' crowd.
>
> Remember that REST is just a vague concept like MVC. It just means to
> use a meaningful URL structure. It' doesn't say what those URLs
> should be, which HTTP methods to use, or what to name your controller
> actions. map.resource/ATOM is a particular implementation of REST,
> not REST itself.
>
> map.resource makes a lot of sense for things that will be aggregated
> or called by programs. It makes some sense for things that will be
> called only through an interactive web browser, but there are
> tradeoffs. Using pseudo-PUT and DELETE in web browsers is
> questionable. Having a "/foos/1/edit" that PUTs to "/foos/1" is
> funny; why not post to the same URL as the form? Why is there no
> delete confirmation form ("/foos/1/ask-delete", which I add to every
> resource).
> One of the things I want to add to Routes 2 is a
> simplified add/modify/delete structure for cases where map.resource is
> overkill. (And one that enables only specific actions; e.g., no
> delete or no index.)
Word up to that. I've written two versions of functions that do this
in two different projects. They're probably not ready for general
production use, but I'll share the code if you are (or anyone else is)
interested.
> The other problem is nested resources.
> "/incidents/123/entries/456/attachments/789/edit" is really long, and
> fails to show the close relationship of an item to its id. With
> non-numeric IDs, you may not even be able to tell which are items and
> which are IDs. In my old site I had /123/456/edit, which made it
> easier to see the whole URL in the location bar and to type it by
> hand. But I wanted to do it the "right" way in Pylons, and nested
> resources were too precarious and undocumented to be trusted, so I
> ended up flattening the resources to /incidents/123 and /entries/456.
> (All entry IDs were unique, so the latter worked.)
>
> --
> Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---
