Hey Chris,
comments inline:
<snip>
Given a RESTful URL, it seems logical to be able to POST/PUT
collections just like we do singular items. Currently, if an XML file
reaches an action (e.g. create or update), it's processed and
reconstituted as the 'params' hash (see: param_parsers in base.rb and
parsing logic within cgi_methods.rb -- both part of
ActionController). The XML data is then accessible via
params[:xml_root][:some_key] (note: prior to Rails 1.1, the XML root
was not part of the params hash). Anyways, this is great because,
whether our params hash was built from form parameters or a posted XML
file, our controllers can act on the params hash the same exact way
(for singular items):
I agree, reconstitution as a params hash is desirable. Careful about
that "(for singular items)" thing - it's not quite true, you can have
multiple params and even though a param is a key/value pair, there's
nothing saying a 'value' can't be composite.
I'm pointing this out because I think you're getting hung up on
detecting when a given param is a single object or a list of
objects. See below:
(code taken from the AWDwR book)
# POST /articles
# POST /articles.xml
def create
@article = Article.new(params[:article])
...
end
So, we're just passing the params hash to the model for processing.
The conditional logic to support collections, at this point (not
taking ActiveRecord into account), would seem to be fairly easy:
(excuse the pseudo-code, it's late and I don't want to go api hunting)
def create
@articles = ( if params[:articles] exists, we process as a
collection of articles ... if not, we process as a singular article )
...
end
Blech. 
Even those who lines look ugly and you haven't yet included results
checking.
The conditional code may not even need to be in the controller.
Perhaps the heavy-lifting would be offloaded to the appropriate class
methods (e.g. Article.new()) in ActiveRecord.
Article.new returns *one* Article so no, that's not the place.
If you want to create a bunch of articles in one go, that's something
like Article.create_zero_or_more_from_this_hash.
But that method (when you give it an accurate name) looks pretty
smelly and my personal preference is for classes to be really good at
doing as little as possible.
So I'd create an ArticleBatch class that was really good at
maintaining a list of Articles and would forward create/update/delete
requests to each object it's referencing.
And suddenly the whole need to detect a singular article vs many
articles goes away - it's not articles, it's *one* article_batch.
batch = ArticleBatch.new(params[:article_batch])
batch.can_save_all?
batch.errors
batch.save_all
batch.destroy_all
batch.each_article
batch.to_xml
So, if you review my previous mail - you have /articles and /articles/
batch (or /articles_batch - it doesn't matter).
And you have controller methods (maybe in a different _controller.rb
file, maybe not) that do *one* thing really well.
In the end it's a matter of taste and smell. I've seen people
complain about having to create extra classes for their RESTful nouns
and I've seen people opine that REST breaks down a bit in more
complicated systems because you're trying to shoe-horn the concept
(implying that noun classes will litter your project).
Hooey! More classes (that are really good at *one* thing) will set
you free.
Give it a try, you may even end up saying "actually, I need an
ArticleBatch and an ArticleFactory because handling both new and
existing records leads to way too many conditionals".
HTH,
Trevor
