On 4/6/07, Trevor S. firstname.lastname@example.org wrote:
RESTfully speaking, that reads to me like: “here is an updated
representation of the resource at /categories/create” - that doesn’t
make much sense to me (explained below).
I should have been more specific here and added an id.
the entire collection at /categories" - i.e. replacing the whole
collection. Then again, maybe the resource at /categories has
attributes which can be updated independent of its children so maybe
that’s what it could mean. However, I’ve seen many people try to
do that as a way of doing bulk updates to a subset of the
collection which, IMHO, is wrong.
I would ask: why is this wrong? Why can’t categories, in this case,
to any collection of categories, whether that be the entire collection,
subset of such? To me, pluralizing simply means more than one, not the
POST /categories (update several categories at the same time)
That should mean “create a new resource (a child) in the /categories
I think that you are inferring here because you are already familiar
this layout. To me, it seems the natural inference from POST
means that you are posting (updating) more than one category… again,
categories is a plural, so when it is used as the noun, to me, that
should ALWAYS be referring to a plural… you shouldn’t even be able to
/categories/ to reference a singular item… it
should always be referring to a plural item.
DELETE /categories (delete several categories at the same time)
Again, no. That means “delete the categories collection”.
And again, I disagree… it means delete a collection of categories;
is no reason it must mean delete the ENTIRE collection of categories,
a collection in general.
Here’s my take (I put ‘always’ in quotes because this isn’t dogma,
just starting principles):
PUT ‘always’ means “here’s an updated representation of the resource”
POST ‘always’ means “create a new child of the resource”
DELETE ‘always’ means “delete the resource”
GET … duh
I agree completely.
But what’s “the resource”?
/categories => a resource (that happens to be a ‘collection’)
/categories/123 => a resource (that happens to be a ‘member’)
Here is where I think the current idiom breaks apart. Your noun is
implying a collection. If anything, I would think that the resource
should be presented here (if available) is a collection of categories
can somehow grouped together by the id 123.
/categories/new => strictly speaking, another resource - the empty
form you can fill in to POST a new category
/categories/123;edit => again, strictly speaking, another resource -
the form you can use to PUT the category
So, remember when I initially said that “PUT /categories/create”
makes no sense? It’s because “/categories/create” isn’t a resource
IMHO - it’s more like RPC.
Exactly… except, this is the default methodology of Rails… you have
the actions like
I think this last one is exactly revelatory of what I’m trying to say:
instead of referring to collections and single instances differently
(/categories, /category), we are forcing ourselves to refer to single
instances as a member of said collection, instead of as a resource in
Nothing wrong with that, just that it’s
not quite REST.
In the end it looks to me like you’re failing to see the distinction
between /categories and “a subset of resources under /categories”.
Every situation is different but I’d start by treating a subset of
a collection as a different resource:
order is significant
map.resource :selected_categories, :path_prefix => ‘/categories’
This is useful in some situations… but not, I think, in what I’m
about… there are definitely reasons to set up new nouns for special
referencing a set of resources… however, I think the default way
still be to have /categories refer to a collection (any collection, not
necessarily the whole thing) of resources, and /category refer to a
POST /categories/selected_categories #=> makes no sense, don’t
implement update() in selected_categories_controller
When you find yourself wanting to add verbs, take a shot at adding a
Remember tho - ultimately this is all a matter of taste, style and
convention rather than ‘rules’.
Agreed… however, I think that the default style of mappings used by
now will ultimately confuse people on what exactly REST is, and how it
should be implemented.