How to GET a Cup of Coffee(参考記事・英語)に応え、RESTeasy(リンク)(JAX-RS実装)(参考記事)の主なデベロッパであるBill Burke氏は以下のように述べている。
Atomの真価は、まだわたしとうまくいってません。この具体的な例で「multipart/*」のようなものよりどこが優れているのかを示します。クラ イアントまたはサーバで、Atom XMLインタラクションフォーマットをサポートするのが複雑になりました。multipartでは、(Location、Content- LocationおよびContent-Typeヘッダーを通じ)よりずっと圧縮されたフォーマットで同様の情報を納めることができます。 multipartより優れているのであれば、古いURIのコンマで区切ったリストを送り返せばよいでしょう。 RESTに惹きつけられたことの1つ(唯一のことではない)は、サービス間で交換していたデータフォーマットに重点的に取り組むことができたこと、そして 中間プロトコルとの対話を妨げないということです。 今までのところ、わたしにとってAtomは、SOAPに代わる大変魅力的なものです。
Bill de hOra(リンク)は、Atomの重要な7つの側面を概説することで、(別の)Billの質問に答えようとしている(リンク)。
- atom：ID
- atom：アップデート済み
- atom：リンク
- 拡張ルール(mustIgnore、外部マークアップ)
- 日付構成ルール
- コンテンツエンコードルール
- 順序なしエレメント
Bill(de hOra)によると、SOAPでの問題(唯一の問題?)は「最低限のエンベロープは何も定義せず、拡張ルールは間違ったデフォルト(mustUnderstand)を取り、コンテンツのエンコードはエクササイズのままにしていること」であった(今でも?)
それから、これらの原理がどういう点で実際にAtomよりもずっと広範に適応可能であるのかを述べて締めくくっている。
Atom(または、XML)を好んでいなくても、キャリアフォーマットがWebで存続するのであれば、これらの7つのプリミティブに対処する必要がありま す。ドメイン固有のものを好み、AtomやSOAPのような抽象フォーマットでドメインをマップしようとする人によく言うことです。それらに対して身構え ていれば、フォーマットの質や堅固さという点においては80%達成しています。思うにこれは、Webを介した使用または分散化システムでの使用フォーマッ トにあてはまる。杜撰なデータフォーマットがいったんワイルドになると、呼び出し元をリファクタリングすることができず、バージョン化しなければなりませ ん。
Atomの初めのほうの記事では、以下のように述べている(リンク)。
... Atom APIは、いくつかの指針を考慮して設計された。
- 適切に定義されたデータモデル -- スキーマなどあらゆるものがある!
- RPCではなく、ドキュメントファイルの拡張子リテラル型のWebサービス
- XMLおよび名前空間を最大限に活用
- HTTPを最大限に活用
- 確実なため、パスワードが不要である。
SOAPの別の起動方法である。ますます多くの人(参考記事)がさまざまな理由でAtomを受け入れている(参考記事リンク)状況において、今のところは確実に支持を得たRESTの子であるようだ。