is Atom format too widespread?
recently, Joe Gregorio posted his The Atom Publishing Protocol is a failure message and got folks talking again:
...AtomPub isn't a failure, but it hasn't seen the level of adoption I had hoped to see at this point in its life. There are still plenty of new protocols being developed on a seemingly daily basis, many of which could have used AtomPub, but don't. Also, there is a large amount of AtomPub being adopted in other areas, but that doesn't seem to be getting that much press...
ok, not a failure but, in Joe's mind, Atom has fallen short of his expectations.
along another line, Subbu posted his Atom as a General Purpose Format article that sees things a bit differently:
...[T]here has been a slow trend to use Atom as a general purpose payload format for RESTful applications. One of the arguments that gets used is that, by standardizing on such a format makes all services consistent and easy to use. This, IMO, is suboptimal, and the benefits of doing so are, in some cases, pedantic.
and i see it in another light. similar to Subbu's point, i think Atom has been used in very inappropriate situtations. in fact, i think Atom is becoming too widespread. proof of this can be found in Subbu's example from Google's Code Search API and from (my current challenge) the Azure Table Storage (ATS) Atom format. in both cases, almost all the important data is stored in a custom extension. in fact, in the case of ATS, the <title> element is not even used for Atom entities!
the problem w/ using Atom as an envelope for custom payloads is that this runs counter to the very nature of the Atom format. instead of publishing data using standard elements understood by a wide collection of client applications, people are using Atom to pass proprietary data objects understood by a limited set of clients. in effect, the Atom envelope is not needed. it's just extra cruft.
Atom extensions are not bad. Atom supports them and several are proposed as of this writing. but these extensions are optional and using them does not 'invalidate' the feed for clients that do not support them. that's not the case for the Atom extensions used in Microsoft's Azure Table Storage and Google's Code Search.
when the extension is not optional, it's not an extension, it's a new media type and it should be treated as such.
so let's stop the widespread *misuse* of the Atom format, ok?