I agree, to an extent.
Having had a bit of time to stew on this issue, I'm coming to the
conclusion that there needs to be more of a separation of concerns.
Fetching records should not be lumped into the same call as updating /
inserting / deleting - ie. _bulk_docs. However, I reckon _bulk_docs as
it is is trying to do too much - why not go for something like the
following:
_bulk_get
_bulk_insert
_bulk_update
_bulk_delete
This way, a request will only ever have one purpose, and the response
can be simpler and more relevant, especially where errors are concerned.
Maybe change insert / update for put / post in terms of naming, but you
get the idea.
Troy Kruthoff wrote:
Getting the API future-proof as possible before 1.0 release is more
important than backwards compatibility. The main reason I am a
proponent of a bulk_docs api supporting the REST verbs is IMHO it is
easier to use and understand than having multiple API end-points to
accomplish RESTful access in a performant manner. Couch is marketing
itself (among other things) as a RESTful database for web apps, which
is an obvious buzzword and one that I believe will aide in the
adoption of the technology, but the fact is we are having this
discussion because we need more performance than what the RESTful
access is bringing to the table.
So, to the web developer we can say:
"When you only need to access 1-5 documents for you web page, use the
REST api. If you need to get 100 documents, modifiy them and save
them back, then use the bulk_load api to get the documents and the
bulk_docs api to save them, because we are the RESTful database built
for tomorrows web apps"
The message that I believe is more marketable, easier to understand
and use is that you can wrap multiple REST calls into a single request
to the server by POSTing your requests as a JSON payload to the
bulk_docs uri when you want to achieve maximum performance (or
_transaction, or bulk_rest, or any other name).
-- troy
