David Van Couvering 's Blog

Why use Atom Publishing Protocol for REST?

I've been working with a group of folks here on prototyping an application architecture that presents relational entities as REST endpoints (yes, I'm sure some of you have already done this, but now it's our turn :)).

We decided to build our REST services using the Atom Publishing Protocol, or APP. This is a common recommendation, and what's good for Google was good enough for us :).

But as we did the work, it seemed like a lot of overhead to put all this APP framework around a very specific application. Why not just use HTTP and JSON and have done with it?

Well, we didn't have a clear answer, so we thought we'd ask the experts here at Sun, and sent an email off to Tim Bray and Dave Johnson. Rather than (mis)quote what they had to say (or the conclusions of the other folks on the team), I'll summarize what my conclusions were at the end of this discussion. I'll let Tim and Dave (or anybody else) comment if they feel so inclined. But I do want to thank Tim and Dave for their very helpful and valuable input.

First of all, I think we should stick with Atom, even with the overhead. Why? Here are some of my reasons:

• APP lets you post a new entry without having to know its URI. The protocol lets the server tell you where it put it as part of the response. This allows the server to allocate things as it sees fit, and decouples the client and server. This feature also seems key to me for solutions that need to scale -- you don't want to hardcode locations into the client.
  
  
• Because APP and Atom are growing and popular standards, lots of products are or will be working with it. As a simple example, when I was testing my Atom server with my browser, at first I was just getting raw XML displayed (through a plugin). But when I finally got the response right and sent a valid Atom feed, all of a sudden Google Reader popped in and asked me if I wanted to subscribe to the feed. Sweet!
  
  I tried to subscribe, but it didn't work, because Google didn't know how to connect to localhost. But Firefox Live Bookmarks worked great!. My content is in JSON so it's not too helpful, but if I had an alternative HTML representation, people could subscribe to my service without any effort on my part.
  
  
• Because APP and Atom are growing and popular standards, people are providing and will continue to provide tools to make it easy to build APP servers and clients. ROME and Apache Abdera are just two examples of this.
  
  
• Finally, supporting APP makes me buzzword-compliant. All things being equal, there's something to be said for that :)

So, tell me what you think. Am I missing anything? When do you think it doesn't make sense to use Atom/APP for your REST service?

Comments

• David,
  I might be missing the whole point, but if I was to decide whether to pull Atom into my application this reasoning alone wouldn't convince me.
  First, you can easily emulate the POST technique used in Atom without using Atom itself. Alternatively, you can provide an additional endpoint that would give clients the URIs for newly created resources.
  Second, HTTP is a popular standard as well, especially if you provide an alternative HTML representation ;-)
  

  Posted by: alexter on March 21, 2007 at 01:30 PM

• 
  alexter: I'm thinking, I'm thinking... :)

  I don't like the approach of having a separate endpoint to find the URI for the thing I just created. That involves a second network hop which I'd prefer to avoid - if I were to emulate this in raw HTTP I'd include the newly created URI in the response.

  I suppose you could do all that Atom does for you in basic HTTP. But I guess: why not use Atom, rather than bake it into your own proprietary format/protocol?

  For instance, I like the idea that by following the APP standard, you could potentially support ad-hoc publishing clients like a blog client on a phone. I don't know if you ever would need that, but it's nice to leave the door open

  That said, I don't think it's a "case closed" kind of resolution. I think that there are options to consider. I do like the simplicity of JSON over HTTP, especially since I don't have to muck with a DOM...

  Posted by: davidvc on March 21, 2007 at 02:15 PM

• David,
  Agree that double request is ugly.
  When I asked myself explicitly what guideline I would use to choose between a lower level and a higher level protocol I realized that the answer is quite trivial: given that both are standards I would choose the higher level one if and only if it would define at least part of the notions/operations I needed (and not prohibit/overcomplicate the rest). Just to do as many things as possible in the same way others do them.
  Creating a resource without knowing its URI is one reusable operation in Atom. But looks like there are other useful things. For instance, aren’t Atom’s collections something that would naturally emerge when exposing relational stuff on HTTP? Again, “services document” seems to be a way to describe your service in a form understandable for others.
  I’m starting to think that Atom is a good choice.
  Please keep us posted on your decision and any additional concerns if they emerge – the subject is very interesting.
  P.S. One possible argument against Atom is _potential_ increase of client size (yes, plain old kilobytes :) ). Not sure if it matters in your case at all.
  

  Posted by: alexter on March 22, 2007 at 09:40 AM

• 
  I think you have a good point, the 'service document' is a nice feature too. There is also the upcoming WADL standard that may be useful for describing the service, although I know very little about it so far.

  Posted by: davidvc on March 23, 2007 at 09:33 AM

• Oh, one more thing: I do think it's good to think about performance. The payload overhead for Atom is really quite small, IMHO, not worth considering.

  However, what is worth considering is if you decide to use one of those nice API packages on top of Atom (e.g. Rome or Abdera), or an equivalent in JavaScript or your client language of choice. That means more bits to download to get the API package onto your client machine. Something to think about...

  Posted by: davidvc on March 23, 2007 at 09:35 AM

• Very interesting you brought this up. I am working on a specification for such an architecture leveraging APP for entities in arbitrary domain models (of course realized using relational entities in many cases).

  I'd be very interested in discussing your findings and knowing about your status.

  Posted by: yeah on April 01, 2007 at 11:11 PM

• yeah: Please feel free to contact me directly at david dot vancouvering at sun dot com.

  Posted by: davidvc on April 02, 2007 at 10:12 AM

• 
  The OpenSource project JeCARS also implements REST services using Atom/APP.
  It also implements some GData features. The Atom/APP standard served our needs well.
  Alltough the lack of good client Atom software/libraries is a problem.
  

  Posted by: weertj on October 05, 2007 at 01:29 PM

This work is licensed under a Creative Commons License.