Skip to main content

I'd Rather Batch than Fight

We need HTTP batching. Or at least some people do, in some situations. I think that a small optimization here can avoid re-inventing a lot of wheels.

To back up a bit, the problem I want to solve is just the one of minimizing round trips for REST based services such as AtomPub. Not atomic transactions, nor additional semantics; just avoiding the latency incurred by multiple round trips. The motivation is basically the same as for HTTP Pipelining.

The ideal solution would work for all types of requests (not just Atom, or JSON, or ...). Batching is orthogonal to all of these and with the use of mashups it's quite possible for a client to be using any or all of them. Batching should work really well within browsers but also be usable with any HTTP libraries. And, it should be auto-discoverable, so a client can fall back to individual requests if a server doesn't support batching.

My canonical motivating example is a smart client that is doing an update and then a retrieval of two different but interdependent resources. The client knows that the update is almost certain to trigger a need for a refresh of the second resource, and you need to ensure that the operations are performed in that order due to the dependency. It turns out to be very difficult to model this as a single REST operation, and it's really two logical operations anyway.

Proposal: Take James' multipart-MIME batch proposal, but use POST instead of PATCH. (I agree with Bill de hÓra that PATCH is a stretch; if we had a BATCH method that'd be fine, but we don't right now.) Make the semantics exactly as if the requests had been sent, in order, from the same client on the same keep-alive connection. Do not provide any atomicity guarantees. Provide an easy way for a client to determine if a server supports batching. If a server does not, then a client has a trivial for loop fallback which won't change the semantics of the request at all.

Q: Why drag in MIME? Why not just use XML/JSON/...?
A: Because you don't want to mandate a particular parser, or even a text based format. Image uploads, for example, should work fine with this scheme. It's generic. Note that we are in fact tunnelling HTTP requests here. I'd much rather be up front and open about this than try to hide the fact by smuggling it inside some other syntax.

Q: But MIME is ugly and not supported by my language!
A: We're not trying to interoperate with mail or Usenet here, just slice up a body with a separator that is a sequence of bytes (--batch-34343434) and apply some simple mapping rules for things like method and URL path.

Q: Do we really need this?
A: If you think you do, you can implement it. If you don't, you can skip it. You'll interoperate either way. Let the market decide what's best.


  1. Hi,

    Didn't quite follow how this batching method is better than pipelining - which is much more wildly supported. We use more BW with pipeline due to the HTTP, but we use a lot less CPU on both sides (client/server) since we don't need to parse.. What's the point then?


  2. @Liorsion -- pipelining only allows GET and HEAD, eliminating the most compelling use case. (Read only batching can already be achieved by defining an appropriate read-only feed and retrieving that.) Also, it's not turned on out of the box in FF or IE so it's effectively not available to browser-based clients.

  3. John,

    That's true, BUT you're talking about defining something new anyway - and hoping people adapt. It makes more sense (to me) to extend something known other than creating something further from what we have - that is, it's easier to extend pipelining than create multiparting batch requests, IMHO.


  4. The biggest difference is in the case of browsers hosting AJAX apps. A pipelining extension requires new browsers, something that takes years. An agreement on an HTTP based protocol however can be deployed in a matter of weeks.


Post a Comment

Popular posts from this blog

The problem with creation date metadata in PDF documents

Last night Rachel Maddow talked about an apparently fake NSA document "leaked" to her organization.  There's a lot of info there, I suggest you listen to the whole thing:

There's a lot to unpack there but it looks like somebody tried to fool MSNBC into running with a fake accusation based on faked NSA documents, apparently based on cloning the document the Intercept published back on 6/5/2017, which to all appearances was itself a real NSA document in PDF form.

I think the main thrust of this story is chilling and really important to get straight -- some person or persons unknown is sending forged PDFs to news organization(s), apparently trying to get them to run stories based on forged documents.  And I completely agree with Maddow that she was right to send up a "signal flare" to all the news organizations to look out for forgeries.  Really, really, really import…

Why I'm No Longer On The Facebook

I've had a Facebook account for a few years, largely because other people were on it and were organizing useful communities there.  I stuck with it (not using it for private information) even while I grew increasingly concerned about Facebook's inability to be trustworthy guardians of private information.  The recent slap on the wrist from the FTC for Facebook violating the terms of its prior consent agreement made it clear that there wasn't going to be any penalty for Facebook for continuing to violate court orders.
Mark Zuckerberg claimed he had made a mistake in 2016 by ridiculing the idea of election interference on his platform, apologized, and claimed he was turning over a new leaf:
“After the election, I made a comment that I thought the idea misinformation on Facebook changed the outcome of the election was a crazy idea. Calling that crazy was dismissive and I regret it.  This is too important an issue to be dismissive.” It turns out, though, that was just Zuck ly…

My faxed letter to both my Senators this morning

My faxed letter to both my Senators this morning.

Senators Grassley and Graham, this morning, engaged in an obvious act of witness intimidation. They leaked a letter to the Justice Department referring criminal prosecution against Mr. Steele for alleged but unspecified false statements to, apparently, the FBI.

This is on the heels of Senator Grassley refusing to release the testimony of Fusion GPS, refusing to allow the public to evaluate the claims of Simpson vs. selective and apparently inaccurate leaks of said information from the Republican members of the committee.

This is outrageous.

It is unacceptable. It is un-American. These Senators are trying to achieve in then court of public opinion what they have no chance of doing in a real court. They are themselves engaging in witness intimidation & obstruction of justice.

I call on you to denounce this desperate and illegal act by your colleagues and to introduce a motion to censure these two sitting Senators who have demeaned th…