snellspace.com

So GData currently implements a batch update model that is based on a modified Atom feed. Each entry in the feed represents a CRUD operation to be carried out against a collection. Entries can be created, updated, deleted or queried. I’ve been watching the effort for a while now and have been planning to write up some thoughts on the subject but just never seemed to be able to get around to it.

First of all, let’s take a look at an example of a GData batch update:

<?xml version="1.0" encoding="UTF-8"?>
<feed
  xmlns="http://www.w3.org/2005/Atom"
  xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/"
  xmlns:g="http://base.google.com/ns/1.0"
  xmlns:batch="http://schemas.google.com/gdata/batch">
  <title type="text">My Batch Feed</title>
  <entry>
    <id>http://www.google.com/base/feeds/items/13308004346459454600</id>
    <batch:operation type="delete"/>
  </entry>
  <entry>
    <id>http://www.google.com/base/feeds/items/17437536661927313949</id>
    <batch:operation type="delete"/>
  </entry>
  <entry>
    <title type="text">...</title>
    <content type="html">...</content>
    <batch:id>itemA</batch:id>
    <batch:operation type="insert"/>
    <g:item_type>recipes</g:item_type>
  </entry>
  <entry>
    <title type="text">...</title>
    <content type="html">...</content>
    <batch:id>itemB</batch:id>
    <batch:operation type="insert"/>
    <g:item_type>recipes</g:item_type>
  </entry>
</feed>

If the mere sight of this doesn’t give you shivers and shakes, let me give you a few reasons why it should:

• It’s not valid Atom. Note the first entry in the feed for instance. An Atom entry has an id, a title, some content, an author, some links, maybe some categories, etc. If the type of objects you want to represent does not also have those things, Atom is not the right format to use.
• It only works with Atom. What about binary resources like Jpeg’s? I guess we could base64 encode the binary data and stuff that into our invalid Atom entries but doing so would suck.
• We can’t use Etag’s and conditional requests
• I’m sure there are more reasons but these should be enough to convince you that a better approach is needed.

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.

Now consider the response:

HTTP/1.1 200 OK
Content-Type: multipart/mixed; boundary=batch-response

--batch-response
Content-Id: <batch-1>
Content-Type: application/atom+xml;type=entry
Batch-Operation: POST /my/atompub/collection
Host: example.org
Batch-Status: 201 Created
Location: /my/atompub/collection/entries/1
ETag: "ABCDEFGH"

<?xml version="1.0"?>
<entry xmlns="...">...</entry>

--batch
Content-Id: <batch-2>
Batch-Operation: DELETE /my/atompub/collection/entries/2
Host: example.org
Batch-Status: 412 Precondition Failed

Each part represents a response to a batched request. The Content-Id correlates with the Content-Id’s used in the request. The Batch-Operation is echoed back for further correlation. The Batch-Status provides the result of the individual operation. Various headers such as ETags can be included in the part, etc.

Note that this approach works well with non-Atom resources as well. For instance, if I want to post multiple images to an Atompub media collection, I could do:

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: image/jpg
Slug: Trip to Hawaii

{image data}

--batch
Content-Id: <batch-2>
Batch-Operation: POST /my/atompub/collection
Host: example.org
Content-Type: image/jpg
Slug: Trip to Alaska

{image data}

--batch--

This approach allows us to take advantage of lost-update detection using Etags, allows support for more than just Atom entries, does not require us to compromise the validity of Atom, etc. It is also very similar to pipelined HTTP requests.

In any case, I’ve got an implementation of this almost complete. Feedback is definitely welcome, especially feedback that points out any fundamental flaws.

This entry was posted on Saturday, October 27th, 2007 at 7:13 pmand is filed under Technology, Atom 1.0, Abdera, Java, standards, opensource.
You can follow any responses to this entry through the Atom Comments feed. Responses are currently closed, but you can trackback from your own site.