Hello,
Sorry if this has been answered in old posts, I couldn’t find anything.
This has been killing me all the morning 
I’m a bit new to REST, and
I’m trying to model my app routes ‘restfully’, but I get lost on many
things.
I’ve been searching how to do this with resources:
I have a Service model that has many Sections, and Sections have and
belong to many Contents. But the Contents don’t have to be in a Section
(it’s optional).
I want to be able to add a content to a section, and remove a content
from a section. With nested resources I could do something like this:
map.resources :services, :shallow=>“true” do |service|
service.resources :sections do |section|
section.resources :contents
end
end
map.resources :contents
But it isn’t what I’m searching. I want to do something that allows me
to have a route like “POST /services/32/sections/14/add_content/5”,
because “POST /services/32/sections/14/contents/” would create a content
in the section 14, but I don’t want a new one. I only want to add an
existing content to a existing section (or delete it). I saw somewhere a
forum post proposing something like (adapted to this case):
map.resources :services, :shallow=>“true” do |service|
service.resources :sections, :member=>{:add_content=>:post,
:remove_content=>:delete} do |section|
end
end
map.resources :contents
But the “member” functions only allow me to operate on the section, and
I cant specify the content id (only by giving a ?content_id=5 after the
URL). Is there anything I can do without falling back to map.connect?
Best regards and thanks in advance,
Diego.
If you are adding member methods like “add_content” and
“delete_content” then you have left REST behind.
I understand that a Service is a resource that has many Sections. The
content already exists, but you want to add it to another section.
HABTM associations are usually processed by a list of checkboxes named
“section[contents][]”. So in your edit form for the Section, you offer
the checkboxes. In the update action of the Section, the checkboxes
get processed automatically when you update attributes.
David Furber wrote:
If you are adding member methods like “add_content” and
“delete_content” then you have left REST behind.
I understand that a Service is a resource that has many Sections. The
content already exists, but you want to add it to another section.
HABTM associations are usually processed by a list of checkboxes named
“section[contents][]”. So in your edit form for the Section, you offer
the checkboxes. In the update action of the Section, the checkboxes
get processed automatically when you update attributes.
I understand that the add/remove thing is a bit against REST philosophy,
but I hoped that some intermediate solution could exist.
I read about the checkboxes, but a section could have as much as
thousands of contents. In this case, obviously I can’t offer the
checkboxes. Even if I leave some of them hidden, I don’t know if sending
a request with thousands of content_ids is a good thing :S
If there isn’t a compromise solution in REST I guess I’ll have to stick
to a more ‘classical’ approach on this. 
Any other advice?
Thank you so much.
You could try to integrate with a JavaScript solution like
http://j.mp/4LdS8r
(see the example) then you should send the data to the server like in
the checkboxes way: “sections[contents][]”.
Here’s the link of a simple jQuery plugin I created for that (it’s a
little incomplete) http://github.com/samflores/tagger.js/
Samuel Soares flores wrote:
You could try to integrate with a JavaScript solution like
http://j.mp/4LdS8r
(see the example) then you should send the data to the server like in
the checkboxes way: “sections[contents][]”.
Here’s the link of a simple jQuery plugin I created for that (it’s a
little incomplete) http://github.com/samflores/tagger.js/
Thank you Samuel -your plugin seems ok to me-, but the problem remains
the same: I have sections with over 4,000 contents, and I think it’s too
much load to use it in the normal requests. I’m thinking in modelling
the habtm relationship between section and content with an independent
object, and change the habtm to has_many :through. That way, I believe I
can keep the REST pholosophy, but it feels someway ‘unnatural’ on the
model.
I’ll stay tuned to the advices of the rest of the rest gurus
(ba-dum-tsh!) 
Regards
I’m a bit new to REST, and