Magnificent Seven - the value of Atom

Bill Burke: "For me, the value of Atom haven’t really clicked with me yet.  Its just too SOAPy for me.  If you look at ATOM, the ATOM protocol, and how people are talking about using it, they’re really using it as an envelope.  One of the things that attracted me to REST was that I could focus on the problem at hand and ignore bulky middleware protocols (like SOAP) and lean on HTTP as a rich application protocol."

Great question and very important as Atom/AtomPub and things "REST" go through a hype phase. For me, the value of Atom is wrapped up in

  1. atom:id
  2. atom:updated
  3. atom:link
  4. the extension rules (mustIgnore, foreign markup)
  5. the date construct rules
  6. the content encoding rules
  7. unordered elements

the problem with SOAP (as opposed to the WS cruft that followed) was that the minimum envelope defined nothing, the extension rules took the wrong default (nustUnderstand) and content encoding was left as an exercise.

Even if you don't like Atom (or XML for that matter), if your carrier format is going to survive on the web, you need to have addressed these 7 primitives. This is what I tell people who prefer something domain specific and direct instead of trying to map the domain in abstract  formats like Atom and SOAP - square off those and you're 80% there in terms of format quality and robustness. This applies I think to any format for use over the web or in a decentralised system, not just XML. Once a sloppy data format gets into the wild, you can't just refactor the callers, you have to version. And version. And version.

"Maybe I just haven’t seen the light yet.  It took me months to accept REST as a viable way of doing things.  Maybe I just need somebody to yell at me about ATOM."

You'd never know going by Bill's posts to the JSR311 list. I can't wait for the major Java stacks to have decent options for REST style web apps.

Tags:

3 Comments


    Great post, thanks Bill. Definitely summarises for me things that I've learnt the hard way to always consider when defining a data interchange format and processing rules. Fortunately more and more people seem happy to use Atom as a starting point and add extensions from there, which deals with most of the hard work.


    Ok so if you had a large public project that standardized wrongly on SOAP some years back any suggestions on how to move to Atom and also, have you looked at that and version and version link recently because the comments there are really uh something.


    It was Vinoski that beat me into submission about REST about a year and a half ago. Thanks for adding to the beating that Subbu gave me on Atom. I'll keep an open mind.