Voltron I have read through the threads you referenced again and I think I can see where you are coming from.
I think that part of the problem is that examples of REST rarely seem to include the parts of the user interaction where the user requests an HTML form to be used to create/update/delete. The examples seem to assume knowledge at the client end that would enable a PUT, POST or DELETE to be generated without any prior GET. I can see how this is possible but this is not generally the case with HTML interactions, hence the need to encode additional information in the GET to differentiate between: - return a list and return a create form - return a read-only version and return an edit form (with an option to delete?) Taking the list vs create case, which of the following forms of GET would you prefer to see (assuming .../default/locations returns a list): - ...default/locations/create - ...default/locations?form=create - ...default/createlocationform It would be a shame if you selected the last one :-) as I think that all the "locations" requests going through the same controller/action has a certain elegance. Whichever you select, I assume that "search" would be handled similarly. Taking the read-only vs update/delete case, which of the following forms of GET would you prefer to see (assuming .../default/locations/1 returns a read-only version, i.e. not a form): - ...default/locations/1/update - ...default/locations/1?form=update - ...default/updatelocationform?id=1 As for the "POST" or send part of the interaction, you suggest overloading POST via a CGI parameter (after the ?). This seems equivalent to overloading via a URI element (?_rest_method=DELETE versus /delete) but I think a parameter is better as it leaves a cleaner URI. The only downside is a lack of symmetry between the GET and POST for create and update but I don't think that is significant. The revision would mean that the POST for create and update would look like: ...default/lookups?_rest_method=PUT&etc ...and the action determined by the id parameter (present and non-zero for an update, absent or non-zero for a create). Depending upon your responses, I would be happy to write up an alternative example to enable people to compare. What do you think? On Oct 23, 6:07 pm, billf <[EMAIL PROTECTED]> wrote: > Voltron > > As I say, REST is new to me, but I believe the practical problem is > the lack of true REST clients. Most of us have to make do with HTML > forms from clients that only support GET and POST. If someone wants > to develop a real-world app using REST "style" URIs then I think > something like I propose would be necessary. > > To cater for true REST clients, it would seem easy enough (from your > links) to handle both. For example, (pseudo-code) if (http- > method==DELETE) or (http-method==POST and request.arg[-1]==delete) do > delete(). > > Whether checks are performed as decorators or inline ifs seems beside > the point. > > On Oct 23, 5:40 pm, voltron <[EMAIL PROTECTED]> wrote: > > > I am not sure if your proposal would work with RESTful clients > > because you are not using the HTTP protocol to differentiate the > > actions taken. > > > What about using decorators? > > >http://pylonshq.com/docs/0.9/module-pylons.decorators.rest.html > > > Or a workaround as Massimo suggested once > > >http://groups.google.com/group/web2py/browse_thread/thread/8506105246... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
