[PATCH] HTTP PUT to a resource collection should be mapped to a standard controller action.

I've attached the patch, which includes tests. Note that I had to disable the existing suspiciously-named test "test_should_not_allow_delete_or_put_on_collection_path"

Sorry but I really disagree with DELETE and so I can't +1.

There is an apparent lack of symmetry here:

DELETE /people/1
GET /people/1 #=> 404

DELETE/people
GET /people #=> 404?  I think not

I feel that PUTting an empty set is the correct way to achieve "delete everything". As in:

• If /people is an empty set and you PUT 10 subordinates into /people that makes sense.
• If /people has 10 subordinates and you PUT an empty set, the existing set of 10 subordinates will be replaced with an empty set of subordinates - and it recognizes that /people as a resource always exists.

You already know I'm in favor of PUT - is there any chance you can put the DELETE enhancement in another ticket and scale this back to just PUT?

Trev

protocool: I had an uneasy feeling about DELETE at one point, but I've found good reason to accept it (more on that in a moment).

First, on the subject of symmetry: REST doesn't guarantee that all resources will behave the same to the same state transfer. There is usually an understanding that a URI that accepts entities for processing (collection) is different from a URI that represents a single entity. There are other examples (in practice) that exhibit a distinct lack of symmetry:

POST /people/1  => normally an error
POST /people    => ok, append the entity to the collection

Second, there are some design patterns that will need a DELETE on a collection. IIRC, the composite pattern strives for a common set of operations on leaves and interior nodes. If we block DELETE on collections (the logical representation of interior nodes), we've denied REST to that pattern.

Lastly, "in theory" there is nothing preventing my application from returning a 404 after a DELETE on a collection. And, while strange, there are valid cases for a POST to a member entity (appending content to a log, for example).

My point is this: PUT against a collection, DELETE against a collection, or POST against a member are all likely to be valid semantics for somebody. I'm in favor of providing the avenue for them to use RoR REST if that's their cup of tea.

All that having been said, I'm willing to split the ticket if that's what it takes to get your +1 -I appreciate your early support on this. Just say the word.

See #11040 for the ActiveRecord corollary to this ticket.

:collection => { :index => :any } doesn't work for you?

Replying to bitsweat:

:collection => { :index => :any } doesn't work for you?

Wouldn't that simply route PUT on the collection to index? It should route to a specific action for replacing the contents of the collection. Likewise, DELETE should route to a specific action for deleting the collection.

-Chris

Patch with actual patch and tests.

Replying to bitsweat:

:collection => { :index => :any } doesn't work for you?

I agree with Chris. Routing all of the verbs to a single method gives you:

def index
  if request.put?
  elsif request.delete?
  elsif request.get?
  end
end

which is a pretty fat method even without respond_to blocks.

Routing PUT and DELETE to replace() and clear() nicely rounds out resources and maps very well to the concept of a 'collection' and to the already-familiar [].clear() and [].replace() methods.

I've tested the patch and, pending documentation patches explaining the routes and methods, consider it a hearty +1.

You said

"Currently, it is necessary to add a meaningless suffix to any collection URI that needs to support such an operation:"

I suggested that is not the case.

Anyway. The patch looks good, though it does add two extremely-rarely-used routes per resource to every app out there.

Replying to bitsweat:

You said "Currently, it is necessary to add a meaningless suffix to any collection URI that needs to support such an operation:" I suggested that is not the case. Anyway. The patch looks good, though it does add two extremely-rarely-used routes per resource to every app out there.

I don't suppose that is a +1, is it?

So, would you want to add these actions to the resource generators as well?

Replying to cch1:

I don't suppose that is a +1, is it?

I'd call it a -0.1 ;)

I'm inclined to side with bitsweat on this one. Adding some rarely used routes to all apps doesn't sound core-ish. I think this would make a great plugin, though.

After benchmarking (thanks technoweenie/lifo/nzkoz) the impact of this patch, I bow to the inevitable: current route recognition code in ActionController::Routing::Routes.recognize_path charges a high price for each new route and this patch adds two per resource.

Unfortunately, this is probably a poor candidate for a plugin for the same reason (performance) and because the code change in resources.rb is small (one or two lines) compared with the existing code in the relevant methods.

For those who want this external API badly enough, you can roll your own with something like this:

map.connect '/places', :controller => 'places', :action => 'replace',
 :conditions => {:method => :put}