最近、George Reese 氏が クラウド向けに様々なSOAPとREST API使うことに関して、Adrian Cole 氏と経験したことについて書いていた。 InfoQは以前これについてレポートしている。今や George氏の最初の投稿がツィッターや多くのブログで多くの議論を巻き起こしている。例えば、William Vambenepe氏は、多くの点で同意せざるを得ないが、いくつかの点、例えばJSONやXMLなどに関しては同意できない、と言っている。
私は以下の点で同意しません。１つのプロトコルに２バージョンは多すぎる （このリンクにある投稿は別段JSON/XMLの両断論理を議論しているわけではないが、その論理はそのような状況に合っているものだ、と Tim Bray氏が コメントの中で指摘している）。
そしてWilliam氏はRESTがSOAPより優っている、というGeorge氏の発言にも賛成していない。
全ての統合プロジェクトに必ずしも当てはまらないが、Cloud APIのコンテキストにおいては同意します。それが「実用的REST」である限りは。 REST警官を喜ばすような愚かなねじれを含んでいる類のものでなければ。
面白いことにWilliam氏が取り上げた１つの事は、
しっかりしたAPI文書があれば、あなたの助けが必要でなくなってくる。言わずにやって行く（面白いので、George氏のブログにコメントした人を調べてみてください。こう書いてます「APIについて文書化すれば、直ちにRESTでなにかしよう、ということを止めることになる」。冗談で言っていると思ったら本気のようです。）。
Jan Algermissen 氏がWilliam氏のコメントに、大真面目で答えた。
「 ちゃんとしたAPI文書があれば、あなたの助けが必要でなくなってくる。」に関して。APIについて文書化すれば、直ちにRESTでなにかしよう、ということを止めることになる。RESTfulなシステムにおける契約は、メディアタイプであって、API文書では「ない」。あのセクションを"The Bad"に移したほうがいいと思います。http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-drivenを参照。
しかし、Stu Charlton 氏は恐らく大抵の議論に熱く参加しており、彼自身の記事の中でAPIに関する問題を５つに要約している。
- REST APIというのは、意図的に異常状態にしたい場合にはいい。RESTの主張は特定のAPIを「排除する」ことだった。その増殖を促すことではない。
- 誰かがREST APIを文書化すべきでない、と言うときは、APIを持つべきでない、と言っているのである。文書化のことではない。
- すなわち、RESTianがAPIを持つべきでない、というのは、幾分愚かなことである。その代わりになるものを何も提供していないからである。カスタムなメディアタイプは代替ではない。
- このため、私の考えでは、”REST API”の80％に代わる、有効な一般的なメディアタイプが1つか2つ出てくるまでは、イラつく混乱がひどくなるだけである。
- 私は、最近REST擁護者でいるのは非常に難しくなってきているので、諦め半分である。人々はわずか6ヶ月間もつAPIを出荷したいと思っているおり、10年以上にわたって進化するようなシステムを作り上げたいとは思っていない。
Stu氏は、特にJan氏の先のコメントを支持して次のように言っている。
Jan Algermissen氏の 「APIについて文書化すれば、実際はRESTをやっていない」についてのコメントは実際完全に正しいが、冷笑されています。もしAPIをたった今出荷したいだけなら、コメントがいかに空虚に聞こえるかは、よく理解できますが、実際それは、短期な視野ないし、構造的なスタイルで決まり文句のビンゴを楽しんでいるだけです。もし実際に、このスタイルの恩恵を利用したいと思ったら、この種のユースケースにあった一般的なメディアを1つか2つ持つという核心的な課題に取り組むべきです。
RESTは、ほとんどの場合そうであるようだが、Stu氏の記事も議論の両サイドの人達から多くの面白いコメントを産み出すことになった。更に、この論争は 我々の前の記事 、RESTはエンタープライズで成功していると考えられるかどうか、に関連しているのか、そして同様に恐らく、なぜ Jean-Jacques氏が、我々は今やPOST REST/SOAP Worldにいる、と信じるのかを議論してもいいだろう。
RESTが生み出した問題は、今やAPI設計者は誰でも、分散コンピューティングの権威者である無償のライセンスを手にしており、多くのヘッダー、トークン、クエリパラメータ、本体、その他色々のところ、好きなところの、どこにバージョンや証明書のようなものを入れるべきか、そして振る舞いとクエリをエンコードすべきかを芸術的に決めている。私に言わせれば、RESTはソフトウェア業界で最悪の残忍行為を生み出した。
Stu氏は、RESTを使う直接の結果である、と信じている、いくつかのルール変更と共に以下のように結論づけている。
- あなたのサービスのエンドユーザーがプログラマー（あるいはブラウザー）である、と仮定することはできない。私は主張したいのは、もしあなたの目標がプログラマーがあなたのAPIを学習することであるなら、RESTを使う理由はない、ということである。
- たった1つのサイトしかあなたのインターフェースを実装しない、と仮定することはできない。「Webの核心は情報共有である。APIを公開する、ということは、公開者である、あなたは、管理下にある、と思われている。どのように、どの情報を消費あるいは操作すべきの管理下にあるのは、もう一方の消費者、エージェント自身である」
- 「文書化される必要のあるインターフェースのセマンティクスは、あなたのデータやリンクを記述するのに、あなたが使うメディアタイプである。」
- 「しかし、カスタム メディアタイプでこれを行うことは、＃２を意味し、あなたはインターフェースを実装している人間にすぎない。もちろん、あらゆるメディアタイプは、どこからか始めなければならないが、他の人達があなたのインターフェースを＊実装している＊かもしれない、単にそれに話しているのではなく、ということをもしあなたが、理解していないと、それは全く役立たないものになる。
彼の最後のルール変更は、別に取り上げるだけの価値がある。それは何年にもわたって、多くの論争のテーマである。
我々が望める最高のものは、ある人ないし組織が1つないし2つの汎用的なメディアタイプ＋ガイドラインで進化させてくれることである。これらは、プログラマーがアクセスできるデータのwebインターフェースを記述するのを助け、また文書化したものである。ある RESTianは記述言語の考えが好きでない。私はそれは本質的に 80/20の一部に過ぎない、と考えている。もし開発者が、本来その意味する使われ方で、アーキテクチャを＊使う＊なら。
さて、あなたはどう考えるだろう。我々は単によいREST APIを設計する、よく定義されたルールを持っていないだけか、あるいは、JJが言うように、これが本当に失われた原因なのか？