REST でよくある間違い

最初のRESTシステムを設計するとき、誰しもしばしばさまざまな間違いをする。この文書では、間違いを避けることができるように、よくある間違いをまとめてみる。もし何かクリアでない場合、より詳しい情報は rest-discuss で質問して欲しい。

HTTPを使用するだけでは十分でない。 SOAP や XML-RPC を使わずに HTTP を Web サービスで使うことができる。それでも HTTP で SOAP や XML-RPC と論理的に同等のことができてしまう。 HTTP を間違って使おうとしているなら、実際には標準的でよりよい方法があるのだ! 以下の他のポイントでは、人々が HTTP を乱用する方法について述べる。
POST を乱用しない。 POST はある意味で「最も柔軟な」HTTP メソッドである。 POST は他のメソッドよりもわずかにゆるい定義を持ち、情報を送信し同時に情報を取得することをサポートしている。したがって、全てに PSOT を使用したくなる傾向がある。最初に REST Web サービスを作るときは、新しい URI を作成するときだけ、POST を使用するべきだ。 POST が「現在の URI の子として新しい URI を作成する」と決め打ちしよう。よりわかってくれば、リソースをこれ以外の目的で変化させるためにPOSTを用いると決めてもいい。 GET, DELETE, PUT またはそれらのメソッドの組み合わせに分解できるものに POST を使っていないかを自問することは一つの経験則である。
URIの内部構造に依存しない。 REST 設計が多くの URI をセットアップすることと考える人がいる。「/purchases に購買注文を入れて、それを /purchases/12132 みたいに渡して、顧客レコードは /customers にあって…」それは、あなたがホワイトボードに板書きしたりチャットしている間に考えるのに役立った方法だが、サービスの最終的な公開インタフェースであるべきではない。 Web アーキテクチャの原理によると、普通クライアントソフトウェアはほとんどのURIを一つの塊として扱う。言い換えれば、公開 API は URI の構造に依存しないはずだ。その代わりに通常は、サービスのコンポーネントを示すただ一つの XML ファイルがあるだろう。それらのコンポーネントには、さらに別のコンポーネントなどを示すハイパーリンクがあるだろう。次に、ただ一つの URI でサービスを人々に紹介することができる。こうなっていれば、コンピュータとドメインをまたいでどのようにでも実際のコンポーネントを分配することがでる。私の経験則では、クライアントが URI を構築するのは問合せ文字列(query string)を組み立てているときだけである。それらの問合せ(query)はオブジェクトを参照する URI を一つの塊として返す (この URI を構成する文字に触ろうとしてはいけない)。
URIにアクションを入れない。 これは前のポイントから自然に続く。 URI の特に有害な乱用は "someuri?action=delete" のような問合せ文字列(query string)を入れることである。まず、何か安全でないことをするのに GET を使用している。次に、この「アクション URI」と「オブジェクト」URI との間にいかなる正式な関係もない。結局、この "action=" 規約は何かのアプリケーションに特有のものである。そもそも REST はプロトコルからのできるだけ多くの「アプリケーション規約」を排除することが狙いなのだ。
サービスはめったにリソースではない。 REST 設計では、「株価(stock quote)サービス」はそれほどおもしろくはない。 REST 設計ではその代わり、「株価」リソースと株価リソースの一覧を提供するサービスになるだろう。
セッションは関係ない。 クライアントが「ログインする」必要はないはずだし、「接続を始める(start a connection)」必要もないはずだ。あらゆるメッセージについて自動的に HTTP 認証は行なわれる。クライアントアプリケーションは、リソースを使うのであってサービスを使うのではない。したがって、ログインすべきものは存在しないのだ！ REST Web サービスでフライトを予約しているとしよう。サービスに接続する新しい「セッション」を作成することはない。正しくは、自分のために新しい旅程を作成するように「旅程のクリエータオブジェクト」に依頼する。フォームに一部は自分で記入するが、残りは Web の別の場所で手に入れたまったく別のコンポーネントに記入させるということもあり得る。セッションというものがないので、クライアントの間でセッション状態を移動するという問題はない。サーバ側における session affinity（セッションの類似性）という問題もない (それでも、依然として負荷バランスの問題はあるが)。 (訳注: この部分については "A Web-Centric Approach to State Transition" も参照のこと)
プロプライエタリなオブジェクト ID を発明しない。 URI を使用する。常に二つの方法で情報関連づけることができるので、URIは重要である。最も簡単な方法はデータを得るために URI をデリファレンスできるように、データを Web サーバに置くことである。このテクニックはデリファレンスできる URI でしか動かないことに注意しよう。これらの URI (http URI!) は URN や UUID ベースの URI よりも強く好まれる。別の方法は自分のコントロール下にない URI にメタデータを投影できるようにする RDF とその他のテクニックを使うことである。もし UUID のような URI 構文を使用すると、URI の利益は半分になる。それは標準化された構文だが、標準的なデリファレンス能力を持たない。 HTTP URIを使えば、標準化されたデリファレンスメカニズムがあるので、もう半分の利益を得ることができる。
プロトコル独立を気にしない。 適切なリソース操作セマンティクスをサポートするただ一つのプロトコルが存在している。将来別のプロトコルが現れたら、同じ設計を保って単に交互のプロトコルのインタフェースをサポートするのは簡単だろう。一方で、通常人々が「プロトコル独立」で意図することはリソースモデリングを捨てることである。そしてそれは REST と Web の両方を捨てることになる。

全体的に見て、覚えておくべきことは REST が URI を通してリソースを公開するためのものであるということだ。 REST はメッセージングインターフェースを通したサービスではない。

翻訳者メモ(Translator's memo)

原著者は REST 推進者として有名な Paul Prescod さんです。 REST に基いたシステムを設計・実装しようとするときに、陥りがちな間違いについて簡潔に説明されています。翻訳と公開については村田真さんに助けていただきました。特に "6" はほとんど村田さんの訳です。村田さんからたくさん助言をもらって訳文を修正してあるんですが、それでも Paul の文章は僕には難しくてあんまり読みやすい日本語にはなってません。ただ非常に含蓄のある内容ですのでぜひ原文とあわせてご覧ください。訳文に関するコメントは yoheiy at gmail.com 宛にお願いします。(2005-11-27)