在回应 How to GET a Cup of Coffee 这篇文章时，Bill Burke， RESTeasy （一个 JAX-RS 实现）的主要开发者之一，这样谈到：
我始终没能被 Atom 的价值触动，在这个特例里，它又比”multipart/*”之类的好在哪里呢？为了支持 Atom XML 交互格式，你又不得不增加客户端及服务器端的复杂性。通过 multipart，我们可以以一种更加紧凑的格式来获取同样的信息（通过位置 [Location]，内容位置 [Content-Location]，和内容类型 [Content-Type] 报头）。
就算比 multipart 更好，为什么不就返回一个逗号分隔的有序 URI 列表呢？
REST 吸引我的地方之一（但不仅如此）就是你可以关注于你的服务之间交换的数据格式而不是用某种中间协议来在交互中充当隧道。目前来说，Atom 于我而言不过是 SOAP 的另一种更具诱惑性的替代罢了。
Bill de hOra 试图帮助（另一个）Bill 来回答这一问题，并为他列出了 Atom 的七大要领：
- atom:id
- atom:updated
- atom:link
- 扩展规则（mustIgnore, foreign markup）
- 日期构建规则
- 内容编码规则
- 无序的元素
根据 Bill（de hOra）的说法，SOAP 以前（或是现在？）的问题（就一个问题？）在于“最小化的信封什么也没定义，扩展规则采用了错误的默认规则 [mustUnderstand]，而内容编码成为了遗留的功课。 ”
他接着总结到这些原则实际上比 Atom 本身更为广泛适用：
就算你不喜欢 Atom（或就此不喜欢 XML），如果你的传送格式想要在 Web 上生存下去的话，你也必须处理这七项基本类型。这就是我对那些喜欢更直接一点并具体到域，而不是将整个域映射到像 Atom 和 SOAP 这种抽象格式上的人们想说的话——就格式来讲，对此展开进攻你大概就能获得 80% 的质量和健壮性了。我相信它对任意Web 或去中心化系统上所用的格式都是适用的，而不限于 XML。一旦一种稀松的数据格式被放任自流，你不能仅仅去重构调用者了，你只有不断的版本控制，版本控制，版本控制。
……Atom API 设计在思想上与如下几点指导原则保持了高度一致： - 定义良好的数据模型——包括模式及其它一切！
- 文档风格的 Web 服务，而不是 RPC
- 发挥 XML 和名字空间的所有优势
- 发挥 HTTP 的所有优势
- 安全，因此在明文中没有密码
这确实与 SOAP 的开端截然不同，随着越来越多的人 开始出于各种理由拥抱Atom ，有理由相信此刻它是REST 最受宠的一个孩子。
查看英文原文： The Value Of Atom?
评论