On Fri, Jan 29, 2010 at 2:43 PM, Haron Media <[email protected]> wrote: > > 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.
Beware of the RESTafarians. REST solves a certain set of problems, and its best realization seems to be ATOM. But the "don't use cookies or sessions" argument fails to provide alternatives for logging in or restricted access, and makes result sets needlessly cumbersome. You end up putting the result ID (which is really a kind of session ID) in the URL. Or you transmit the whole data to the client and back through request variables, which is unfeasable with large data sets. And it's impossible if the client shouldn't actually see the raw data. And having random result IDs still doesn't answer the question of whether the current request should have access to that result set. So complete statelessness is impossible or at least unreasonably cumbersome. I also notice that all of the most popular social networks abuse query strings horribly, worse than any of us would ever do, yet that hasn't caused the sites to crash or their users to boycott them because their URLs are bad. So REST is not necessary to make the world go round and the sun come up. Still, REST is a good ideal, and it's worth moving closer to it when feasable. But its biggest advantage is for noninteractive clients which don't want to know the particular site's idiosyncracies. Its benefit to interactive sites is less certain, especially those that are heavy on user accounts, result sets, and shopping carts. -- 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.
