Pretty inefficient when you can just slurp all the records in one request.
Make your create action know what to do when it receives a collection
document instead of an item document. Or break REST a little bit and
write a create_many action. As far as handling errors goes, it
depends entirely on what you need to do. You can run all the creates
in a transaction and return an error code if one fails. You can run
them all and make callbacks somewhere, notifying the source app that
one of the creates failed.
2) Depending on my needs, maybe I'll want to validate the items and
let the user verify before actually inserting them into the system.
map.resources :items do |item|
item.resource :buckets
end
POST /items/bucket.xml # import
GET /items/bucket.xml # view current validated items
PUT /items/bucket.xml # confirm and actually import items
DELETE /items/bucket.xml # remove validated items instead of importing them
Yeah, except that the bulk importing doesn't seem to work at all...
because rails maps the bulk to params... and params is a hash, which
as we all know means that the keys get overwritten with every update
(ie if we have a collection thus:)
<blahs>
<blah>
<mep>
Yes!
</map>
</blah>
<mep>
No!
</mep>
<blah>
<mep>
Maybe!
</mep>
</blah>
</blahs>
then our params looks like this:
params = {:blahs => {:blah => "Maybe!"}}
OMG what happened to the other two blah objects?
Well, they're in the params hash, and unfortunatley it's a hash, not
an ordered array of arrays, and so we lost all our key overwrites.