[Catalyst] Re: REST - like uri design for CRUD

Aristotle Pagaltzis pagaltzis at gmx.de
Mon Jan 21 02:16:44 GMT 2008


* Dave Rolsky <autarch at urth.org> [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 <tshinnic at io.com> [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/>



More information about the Catalyst mailing list