Mike Orr wrote: > On Jan 29, 2008 9:40 AM, Ian Bicking <[EMAIL PROTECTED]> wrote: >> Matt Feifarek wrote: >>> Yes, we're disagreeing on what the default should be. Well, you'll >>> have to convince Ben. I think he likes it the other way. >>> >>> >>> I don't have this particular religion, but what would a REST zealot say? >>> Seems like two different URI's for the same thing is bad. >> REST zealots say that you should have: >> >> GET /resource -> rendered thing >> GET /resource/edit -> form >> POST /resource -> make the change >> >> So there is generally another URL involved. But REST zealots don't deal >> with HTML forms. > > This gets into how Pylons should support REST, and what this implies > for the changes I'm making in Routes 2. Ben and I discussed > map.resource a week ago, and he said it follows the Atom Publishing > Protocol, a widely-respected REST spec. I haven't studied it yet but > here are some links on it. > > http://tools.ietf.org/html/rfc5023 > http://www.ibm.com/developerworks/library/x-atompp1/ > > As a recap, map.resource believes that: > > GET /messages => display index page > POST /messages => create new message > GET /messages/new => display add form (action = POST /messages) > GET /messages/1 => display message 1 > GET /messages/1/edit => display edit form (action = PUT /messages/1) > PUT /messages/1 => modify message 1 > DELETE /messages/ 1 => delete message 1 > > (Routes 1 has ";edit" instead of "/edit", but Ben said that's an > invalid URL syntax borrowed from Rails, which Rails has since > corrected.) > > PUT and DELETE are implemented by an "_action" query param to a POST > form, which Routes notices and changes the request method. Again, Ben > says this is widely done in other programming languages.
It's kind of wonky, though, because web applications don't expose "resources". When you get /messages you get an HTML page. You don't get a well-formed container of resources like in atompub. When you get /messages/1 you get HTML again. When you edit you send application/x-form-www-urlencoded (or whatever it is). That's not the same content type as what you were given (HTML). It's not even that close to the same content type. (Though the intention of a FormEncode Schema is actually to take a resource and turn it into something isomorphic to an HTML form, and then convert it back again... but expressing form submissions as a transformation of data is tricky.) As long as you are doing this, you might want to consider some kind of validation submission as well, that can be used by Javascript to submit and get errors. Also a preview submission. 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). Ian --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
