Webサービス開発で無視できない「REST」とは？　REST APIが「RESTful」と見なされるためには何が必要か：完全準拠が難しい6つの「REST制約」

　RESTの中心となるのは、技術的に言えば、REST制約と呼ばれる次の6つの基本原則だ。

　REST制約の6つの基本原則は、上記のリストでカギかっこで囲んで示した用語で表されることが多い。

REST制約の一つ、統一インタフェース

　RESTful APIは、この6つのREST制約に可能な限り準拠する必要がある。当然、REST制約に違反することは許されない。

　RESTful APIの開発者やアーキテクトがよく直面する問題は、6つのREST制約、特に「統一インタフェース」を使用するという原則を完璧に実装するのが極めて難しいことだ。

　RESTful APIは、少なくとも、次の2つの方法でRESTの統一インタフェース制約に従う。

• RESTful URIで「名詞」を使用し、Webサービス操作をリソース上で確実に機能させる
• HTTPの「動詞」を正しく使用し、リソース上での操作を実行する

　リソース重視のRESTful URI命名規則（URIのエンドポイントとして名詞を使用する）に準拠するのは比較的容易だ。一方、HTTPの動詞を正しく使用するのはそれほど簡単ではない。

　例えば、RESTful APIを使ってリソースを取得または削除するには、HTTPの動詞「GET」と「DELETE」を使用する。ただし、これ以外のHTTPメソッドを正しく使用するのは難しいことがある。以下がその例だ。

• 「PUT」操作は、既知のリソースを冪等（べきとう、同じ操作を何度実行しても同じ結果を返す）に作成および保存できる
• 「POST」操作はリソースを更新または更新できるが、冪等ではない
• 「PATCH」操作は既知のリソースを冪等に更新できる

　「PUT」「POST」「PATCH」の各操作に関するこの微妙なルールから逸脱すると、「APIはどれだけRESTful（RESTf的）なのか」が疑問視されることになる。

RESTに完全準拠するためのHATEOAS

　さらに、RESTと統一インタフェース制約では、HATEOAS（Hypermedia As The Engine Of Application State：アプリケーション状態のエンジンとしてのハイパーメディア）のサポートが求められるが、実装されることはほとんどない。

　HATEOASでは、リソース表現をクライアントに送信する際には、そのリソースに対するその後の操作を実行するために呼び出すことができるさまざまなURIも送信する必要があると規定されている。

　技術的には、REST制約に完全準拠するにはRESTful APIでHATEOASを実装する必要がある。ただし、実装されることはほとんどなく、HATEOASの原則を実装していないAPIでも大半の場合 RESTfulと見なされる。

REST APIがRESTfulになる条件

　RESTの6つのアーキテクチャ制約に完全準拠するRESTful APIやWebサービスはほとんどない。とはいえ、大半のソリューションアーキテクトは、HTTPプロトコルのメソッドを尊重するよう努め、リソースベースのURIを使用し、クライアントとサーバ間の疎結合を可能にするステートレスでキャッシュ可能なエンドポイントを作成している。

　こうした条件を満たせば、そのAPIを他のユーザーが簡単に理解して、利用できるようになる。こうした条件が、Webサービスを作成する際の主な目標になるのが一般的で、ほとんどの開発者はこのAPIはRESTfulだと考える。