On 01/29/2010 10:33 PM, Mike Orr wrote: > I don't understand Vlad's point: > > >> Confirmation is a process that is not fully compatible with (pure) REST, >> > because requests must not be dependent of previous ones. > > >> But if you need one, think of it as a "Deletion resource". POST to >> > create a "deletion resource". The response is a form containing a nonce > token, ... > > A pure REST client would not use the confirmation, it would just > DELETE the resource directly. The confirmation step, if any, would be > built into the client itself. But there's nothing wrong with adding > additional GET URLs to resources. That's just asking the resource to > show a different "view" of itself. And if the view happens to contain > a form that submits a delete action, so what? > >
Indeed, but Vladimir's question was without Javascript. It is my belief that "proper" REST is impossible without javascript because HTML does not specify anything other than the URL in links. Additionally forms set the method, but that's about it (plus cookies handled automatically by the browser). Therefore I like to separate (Javascript powered) GUI resources from data resources. However my suggestion stems from the fact that REST is an architecture, not a protocol like for example a SOA implementation. And that architecture requires resources with (original) URIs. Therefore any SOA implementation can be easily translated to REST if proper resources were defined. My suggestion was to observe the deletion confirmation as an additional resource created exclusively for a resource to be deleted. Naturally, "pure" stateless REST is impossible in practice, if nothing then because of security considerations. But statelessnes is a requirement, I would dare say "prescribed" solely because of scalability. However, traditional "sessions" are not necessarily unscalable, especially if using a clustered memcached solution. Still, that depends on the kind of state. Is it application state that is tracked through sessions, or temporary state of data which can still allow independent requests? I believe the latter can be perfectly in line with pure REST. Alternatively to the "deletion resources", given that REST is all about transfer of state, the resource to be deleted can be modifed by PUT to mark itself deletable, then deleted in any of the subsequent, yet conceptually independent, requests. Personally, I find GET-ing the confirmation form is in fact simulating a SOA implementation which breaks pure REST because two adjacent request are dependent. Vlad -- 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.
