I have posted an alternative example based on the last couple of posts which is, I think, an improvement. It can be found at: http://www.wellbehavedsystems.co.uk/web2py/examples/rest_alt1.html
It is fully working (so far) with the exception of: - it doesn't yet generate a read-only details page prior to a delete (but the update form delete checkbox works) - a cosmetic issue: lists are labelled 'resource' as opposed to the table name On Oct 24, 1:40 am, billf <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
