* Dave Rolsky <[EMAIL PROTECTED]> [2008-01-21 00:35]: > What I've done is something like /user/1111/edit_form > > For creation I'd have /user/create_form or /user/new_user_form > and POST to /user
++ * Thomas L. Shinnick <[EMAIL PROTECTED]> [2008-01-21 01:55]: > First, there is a difference when talking about how you go > about implementing RESTful interactions where both the > client/server are programmed, that is, where data is exchanged > directly and people aren't involved. When you instead want to > make accommodations for allowing more classical > (non-Javascript) interactions it _does_ get cloudy. And if you > want to serve _both_ programmed and human interactions it gets > positively foggy. Actually, that’s not true. It looks like that when you first grok REST properly and start to understand, and to some extent it is true, but less so than you would think. Note the REST book intentionally avoids going too meta and describes REST as it actually applies to designing stuff. It doesn’t dwell much on theory. But with a better grasp on the theory, you’ll realise that while the human-oriented web imposes some limitations on designs, it doesn’t force you to depart from REST at all, even if it does make it hard to do a pure ROA design as per the book. The part where web browsers really do suck – and I really mean suck utterly terribly – is HTTP Auth, which makes you have to… well, you don’t quite have to violate REST constraints, but you are forced to traipse into grey areas like cookie-based auth (not sessions!). > You don't want to start having alternate URIs just to specify > what 'kind' of representations to serve. There’s nothing un-RESTful about that. Yes, it’s good not to proliferate names for the same resource, particularly because only the server can know whether two URIs point to resources that share state. But you shouldn’t be frightful about creating new names for a resource when it is really warranted. URIs are not primary keys. They are names for application states. (Hence the name “representational STATE transfer”.) > Basically they keep coming back to the same theme: use HTTP to > its fullest, both headers and methods (e.g. PUT), and much > becomes possible that otherwise seems clumsy. (Didn't say > 'easy'... :-) Yes. REST is simple – not easy.[1] It’s a crucial distinction. In fact REST is sometimes so simple that it’s hard to realise when you’re missing the forest for all the trees and conjuring up difficulties for yourself where doing it the right way would make the problem just go away. REST is very much like a mathematical abstraction: you get a set of concepts that work together and are concise and consistent and in a way beautiful, which are pretty easy to name or list, but aren’t easily understood just by reading such a list. You need to wrap your head around them and get a feel for how they work as a whole. And they’re axioms, not rules for what to do, so to know what to do, you need experience with thinking in those term. The book tries to give you a shortcut to that part, because a lot of people understand better by working their way backwards from hands-on tutorial to an understanding of the theory (and just having a set of rules without understanding them can be enough to get the job done, too, sometimes). [1]: http://tomayko.com/weblog/2008/01/13/lying-through-their-teeth Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> _______________________________________________ List: [email protected] Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
