Atom的价值？

在回应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的七大要领：
 

1. atom:id
2. atom:updated
3. atom:link
4. 扩展规则（mustIgnore, foreign markup）
5. 日期构建规则
6. 内容编码规则
7. 无序的元素

根据Bill（de hOra）的说法，SOAP以前（或是现在？）的问题（就一个问题？）在于“最小化的信封什么也没定义，扩展规则采用了错误的默认规则[mustUnderstand]，而内容编码成为了遗留的功课。 ”

他接着总结到这些原则实际上比Atom本身更为广泛适用：

就算你不喜欢Atom（或就此不喜欢XML），如果你的传送格式想要在Web上生存下去的话，你也必须处理这七项基本类型。这就是我对那些喜欢更直接一点并具体到域，而不是将整个域映射到像Atom和SOAP这种抽象格式上的人们想说的话——就格式来讲，对此展开进攻你大概就能获得80%的质量和健壮性了。我相信它对 任意Web或去中心化系统上所用的格式都是适用的，而不限于XML。一旦一种稀松的数据格式被放任自流，你不能仅仅去重构调用者了，你只有不断的版本控制， 版本控制，版本控制。

实际上一篇最早期的Atom文章提到如下几点：……

……Atom API设计在思想上与如下几点指导原则保持了高度一致：

• 定义良好的数据模型——包括模式及其它一切！
• 文档风格的Web服务，而不是RPC
• 发挥XML和名字空间的所有优势
• 发挥HTTP的所有优势
• 安全，因此在明文中没有密码

这确实与SOAP的开端截然不同，随着越来越多的人 开始出于各种理由拥抱Atom，有理由相信此刻它是REST最受宠的一个孩子。

查看英文原文：The Value Of Atom?