I'm familiar with CRUD and the mapping of the four actions (create, read, update, delete) to the four SQL statements (insert, select, update, destroy).
I have other actions dealing with associations. For example, I want to remove a book from a list. In this case I'm not deleting (destroying) the book record but removing its association from a list. The controller method's code would look like...
@list = List.find(params[:id])
redirect_to :action => 'edit', :id => @list
Although the association method is delete. I don't the user thinking they are deleting the book, and want to convey to them instead that they are removing the book from the list.
I can think of these association related actions:
Remove - remove a record from a list.
Add - to add a record to a list.
Is there a consensus on action names for association related manipulations?
Not a universal consensus. I'd say there are different takes on best
or reasonable practice. One is to use ad hoc method names based on
what's happening, like lists/add_book. I don't think that's so
horrible, but it definitely lies outside any kind of CRUD and/or
RESTful convention and therefore won't garner you any of the possible
advantages of those conventions.
With CRUD edge cases generally, one thing you can do is force the
issue by asking: "If I *were* performing a CRUD operation, what would
it be? And on what entity or resource would I be performing it?"
Here, the answer is that you would be deleting (destroying) a Listing
-- not a List or a Book, as you point out, but an instance of the
connectedness *between* a list and a book.
So... you could have a listings controller, and in it you would do
(refined as needed):
list = List.find(params[:list_id])
book = Book.find(params[:book_id])
list.books << book
# ditto, but remove
There's a second stage to the process, if you want to do it, and that
is to also have a Listing model. If you feel it unnecessarily
complicates your associations to do it that way (it would generally
entail a has_many :through association), there's no overriding reason
to do it. You can still have a listings controller (and I've actually
been finding modelless controllers increasingly useful and RESTful).
But the Listing model is another potential aspect of thinking of the
listing itself as something that your application addresses, not
through book or list but alongside them.