1. If it's a transaction (all-or-nothing) I POST a new transaction resource which references all the target resources. Remember that you can create as many resources as you want. There is no need to have a 1:1 mapping between your resources and the database.
2. If it's a batch statement (some-can-fail-some-can-lose) I simply stick to issuing multiple requests. This frees me and my clients from having to write complicated code that deal with partial success - and it can still be very fast especially with request pipelining.
If issuing multiple statements is too slow then I would attempt to increase the speed of the stack before adding the complexity of having to deal with partial success.
So in conclusion... No really good ideas on how to write batch statements. I don't really think REST APIs with their one HTTP response code maps very well for that use case. But I hope one of the two strategies above will be useful to you.
Not sure how common this pattern is, but one way I've seen this handled is to do a query to get a list of results, the document listing the results (or more commonly, the first page of results) has a link to a temporary resource representing the set of all results, which you can send a DELETE to remove all the members of the set. By analogy, you could send a PATCH to modify all the members instead.
