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
- the extension rules (mustIgnore, foreign markup)
- the date construct rules
- the content encoding rules
- 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.