This post originated from an RSS feed registered with Java Buzz by Bill de hÓra. Original Post: BATCH / HTTP/1.0 Feed Title: Bill de hÓra Feed URL: http://www.dehora.net/journal/atom.xml Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8 Latest Java Buzz Posts Latest Java Buzz Posts by Bill de hÓra Latest Posts From Bill de hÓra

James Snell: "Let’s set a few ground rules. First, assuming that we need batch updates at all, we need a format that can work with more than just Atom entries. Second, we need a format that does not require us to bastardize Atom or use it for purposes for which it was never intended and is not well suited. Third, we need an approach that does not duplicate the disadvantages of the WS-* model by circumventing key elements of HTTP and REST.

Consider the following:

PATCH /my/atompub/collection HTTP/1.1
Host: example.org
Content-Type: multipart/mixed; boundary=batch

–batch
Content-Id: <batch-1>
Batch-Operation: POST /my/atompub/collection
Host: example.org
Content-Type: application/atom+xml;type=entry

<?xml version=”1.0″?>
<entry xmlns=”…”>…</entry>

–batch
Content-Id: <batch-2>
Batch-Operation: DELETE /my/atompub/collection/entries/2
Host: example.org
If-Match: “ABC123XYZ”

–batch–

The PATCH operation is telling the server that the request entity contains a set of instructions for how the server resources are to be modified. The Content-Type value “multipart/mixed” tells the server that the ordering of the parts is significant. Each part represents a single batched HTTP request, complete with headers. The Batch-Operation header represents the HTTP request method and uri. The Content-Id header provides the identifier for each batched request. Notice the each batched request can target a distinct resource."

James is trying to provide a better option than Google's batch uploading protocol. This is better, but it's still problematic.

 I've done enough messaging over http and bulk publishing work at this point to believe that web batching is

1. Complicated because HTTP and REST does not support batching (or contrapositively, iterators).
2. Requires its own uniform semantics independent of any other method.
3. Should be avoided, if possible.
   

I think if it's to be done at all, a BATCH method is required. It really is so different from everything else, that overloading any existing method will be broken. Some specifics:

• PATCH. PATCH is incredibly useful, and I'm glad to see it being revived, but not like this. PATCH is suited for fine grained manipulations of individual resources, the exact details of which vary on the media type. Using PATCH here does consider the media type (multipart/mixed; boundary=batch), but it fundamentally switches on the resource as well, making the resource 'typed'. You have to know that the resource is some kind of master container for surrogate resources. It's the wrong tool for the job.
• Response codes. I think a batching operation has to return 201, 400, 401, 403, 404, 5xx and nothing else. Your batch op is accepted (even if nothing in the payload was), sucked, unauthorised, refused, or the server/upstream bailed. In any case, the response codes for this need serious thought because of the way they react with the nested responses. This alone is good enough for me to say we need a different uniform method.
• multipart/mixed; boundary=batch. Perhaps we need a new media type as well. I think I'd like to see each mime block contain a full and standard HTTP request instead of the  Batch-Operation header. Batch-Operation is another clue that we need a new method.