先ごろRoy Fieldingは、SocialSiteのREST API(リンク)に対して、RESTfulではないと批判した(リンク)。Royは、RESTだと主張するシステムが、多くの場合にRESTから程遠いことの例として、SocialSiteのREST APIを取り上げた。
(OpenSocialのREST API)はRPCです。それはRPCだと叫んでいます。画面のXレートを指定するために、とても多くの結合があります。
Royに同意するための証拠を、OpenSocialのページで見つけるのは(リンク)、それほど難しくない。例えば、
- サーバサイドで、OpenSocialスタイルのRESTとJSON-RPCをサポートする
- クライアントサイドで、リクエストのJSON-RPCバッチ処理をサポートする
- 拡張のために、OpenSocialの要求に従う
RESTとRPCがとても密接な関係にあることは(リンク)(あるいはそうでないことは)、誰でも知っている。Royが見てきた、RESTfulだと主張するが、そうなっていない多くのサイトに対して、彼が指導する、良いWeb(とREST API)のためのベストアプローチの一部を、以下に要約する。
- REST APIは、いかなる単一の通信プロトコルにも依存してはならない。URIを識別のために利用する、いかなるプロトコル要素であっても、その識別のために、どんなURIスキームでも利用できなければならない。(ここでの失敗は、その識別が相互作用から分離されていないことを意味する。)
- REST APIを記述するための努力は、リソースを表現したりアプリケーションの状態を駆動するために利用されるメディアタイプを定義することや、拡張された関連名や既存の標準メディアタイプに対するハイパーテキスト可能なマークアップを定義することに、ほとんどすべてを費やすべきだ。いかなる努力も、関心のあるURIで利用するメソッドの記述を、メディアタイプに対する処理ルールのスコープ内で完全に定義するために費やされるべきだ。(そして、ほとんどの場合に既存のメディアタイプが定義されている)(ここでの失敗は、ハイパーテキストの代わりに、帯域外の情報で相互作用を駆動していることを意味する。)
- REST APIは、固定したリソース名や階層を定義してはならない。サーバは、自らのネームスペースを自由に管理できなければならない。むしろサーバは、メディアタイプやリンクの関連の中に、HTMLフォームやURIテンプレートで行われるような指示を定義することで、適切なURIを構築する方法をクライアントに指示することができる。(ここでの失敗は、RPCの機能的な結合と同等のデータ指向であり、ドメイン固有の標準などの帯域外の情報によって、クライアントがリソースの構造を仮定していることを意味する。)
- REST APIは意図したクライアントにとって適切な、最初のURI(ブックマーク)と標準的なメディアタイプのセット以外の予備知識を持ち込んではならない。(すなわち、APIを利用するかもしれない、あらゆるクライアントに理解できることが期待される)その点から、すべてのアプリケーションの状態遷移は、受信した表現に含まれるものや、それらの表現に対するユーザの操作が暗に示すものなど、サーバが提供したものをクライアントが選択することで駆動しなければならない。遷移はクライアントのメディアタイプやリソース通信メカニズムの知識によって決定(あるいは制限)されるかもしれず、それはどちらも改善されたオンザフライ(すなわち、コードオンデマンド)かもしれない。(ここでの失敗は、ハイパーテキストの代わりに、帯域外の情報で相互作用を駆動していることを意味する。)
Royの投稿は、ハイパーテキストやハイパーメディアを利用する際の規則に関する質問を含む、コメント(リンク)に対する多くのフィードバックと関連する投稿(リンク)をもたらした。Royはそれに対して以下のように返答する。
私がハイパーテキストと言うとき、それはユーザ(あるいはオートマトン)が選択することで情報を得られるような、情報と制御の同時提供を意味しています。ハイパーメディアは、メディアストリームの中の一時的なアンカーを含むことを意味する、テキストの拡張でしかありません。ほとんどの研究者は区別できていませんが。ハイパーテキストはブラウザ上のHTMLである必要はありません。マシンはデータ形式と関連タイプを理解すれば、リンクをたどることができます。
なぜ多くの人々が間違えていると思うのかという質問に、Royは以下のように述べる。
人々がRESTを間違えたのは、ある意味、私がメディアタイプのデザインについての十分な詳細を論文に含めなかったからでしょう。それは時間がなかったからで、RESTのその他の側面よりも、重要ではないと考えたからではありません。同様に私は、多くの人々が間違えたのは、Wikipediaのエントリだけを読んだからだと疑っています。それは信頼できるソースに基づいたものではありません。一方で私は、ほとんどの人々は、シンプルなことをシンプルにデザインしようとして、失敗しただけだと考えています。アーキテクチャのスタイルとしては、RESTはとてもシンプルですが。RESTは数十年の規模のソフトウェアデザインです。すべての詳細はソフトウェアの寿命を延ばし、独立して発展することを目的としています。制約の多くは、短期的な効率とは真っ向から対立します。残念ながら、人々は短期的なデザインはとても上手ですが、長期的なデザインはかなり下手です。彼らの多くは、現在のリリースを超えるデザインが必要だとは考えていません。
実のところ、RESTに興味があるなら、このアーティクルに対するすべてのコメントセクションは、絶対に読む価値がある。Dare Obasanjoは別のアーティクルで、要約と明確化を試みている(リンク)。
覚えておくべき重要なことは、RESTがWebエコシステムの良い参加者となることで、World Wide Webの使用に対してスケールするソフトウェアの構築に関するものだということです。理想的なRESTful APIは、数千のWebサイトで実装可能であり、クライアントアプリケーションとWebサービスによる結合のない、数十のプラットフォームで実行される、数百のアプリケーションで利用可能であるように設計されなければなれません。この優れた実例は、たまたま世界一うまくいったRESTful APIの一つになった、RSS/Atomフィードです。
彼はRoyが述べた事項の一つ、APIを実装するサービスのために特別なURL構造を必要とすることに、特に注目している。
このアプローチの問題は、すべての実装者がURIスペースを完全に制御して、クライアントがそのURL構造を利用すると想定していることです。このプラクティスが悪い考えである理由は、Joe Gregorioの投稿「No Fishing - or - Why 'robots.txt and 'favicon.ico' are bad ideas and shouldn't be emulated(リンク)」にある、ハードコードされたURLが悪い考えであるいくつかの理由のリストでうまく説明されています。この理由には、拡張性の欠如やURIスペースを完全に制御できないホスト環境の人々に対する貧弱なサポートが含まれます。
Web上には、その他にもRESTのリソースが大量にある(参考記事・英語)。その多くは実装した実績のある(参考記事・英語)信頼できる人々(参考記事・英語)によって書かれている。