On Jan 29, 2008 11:45 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: > > Mike Orr wrote: > > On Jan 29, 2008 11:15 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: > >> I think using POST is okay; if you are using _action=PUT it isn't a PUT > >> anyway, and it feels like it's not much more than HTTP verb push-ups. > >> POST over a resource updates the resource in some fashion; updating a > >> resource in-place via POST is okay (PUT might be better, but > >> not-really-a-PUT *isn't* better). > > > > I generally agree with you, and I keep going back and forth whether to > > use map.resource in my own applications. Because what does it really > > matter if you use POST or PUT? Users can't effectively predict URLs > > across applications anyway, and there's no practical reason to; e.g., > > no Google GWebsite that's a common front end for interacting with a > > variety of sites. "/resource/" vs "/resource/1" is a good idea, but > > I'm not sure the rest of it matters. > > > > Are there any other practical arguments for a REST-like > > add/edit/delete, or is it all just academic ideology? > > POST or PUT over a resource automatically invalidates all caches (at > least all that see the request), so that is of some benefit. I like PUT > insofar as it is clearly symmetric with GET. If there is not a strong > symmetry then I don't see any purpose to it. > > POST /resource/1?_action=PUT doesn't invalidate any caches, and so it's > not just rather useless, it's actually counterproductive. > > Technically you could use Accept headers to handle a resource with > multiple representations. But the Accept header totally blows; browsers > lie about it (they claim they'd prefer XML over HTML?!?) and it totally > messes up caching and the fixes are hard to handle. > > > But still, something needs to be done for Pylons, and map.resource > > exists, so I guess a fair number of people are using it. > > Well, for services I think the atompub layout is nice. For rendered > HTML and HTML forms it doesn't work that well IMHO.
I googled around to see how other people are combining Atom and HTML. It looks like Atom is an advantage only if you want to syndicate the resource. And even with that, if you only want to syndicate it read-only but require all changes to be done at the original website, it looks like only the "index" and "show" URLs need to be conformat (/article/ and /article/1), and the modify URLs can be anything. And the index URL would have to provide a bona fide XML atom feed, not an HTML page with hyperlinks. So, I think this means map.resource is good at what it does -- Atom serialization -- but it's not a complete answer for how to organize a set of index/show/add/modify/delete operations in a website. I've thought about keeping map.resource as-is and adding another more flexible method for HTML resources that want to be standardized and somewhat REST-like but not necessarily completely REST, and using GET for forms and POST for execution. I haven't yet gotten into the design, though one-method "foo/add", "foo/1/edit" and "foo/1/delete" are a possibility, optionally expandable to the two-method style (ask_delete, confirm_delete, something like that). Are there any good standards or precendants to guide this? -- 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 -~----------~----~----~----~------~----~------~--~---
