REST（Representational State Transfer）とは？【基礎知識】

REST（Representational State Transfer）とは？

Wikipediaでは、以下のように紹介されています。

RESTは、APIの定義に使用されるアーキテクチャスタイルであり、同時にウェブのような分散ハイパーメディアシステムのためのソフトウェアアーキテクチャのスタイルのひとつでもある。この語はHTTPプロトコル規格の主要著者の一人であるロイ・フィールディング（英語版）がウェブについて書いた2000年の博士論文で初めて現れ、ネットワーキングコミュニティの中ですぐに広く使われることになった。

※ロイ・フィールディング氏が書いた論文は＞＞こちら＜＜

難しいですね。簡単に纏めると、以下です。

RESTは、Representational State Transferの略で、Webサービス設計モデルの一つということです。

HTTPプロトコルを最大限活用できる設計モデルだと言われており、WebサービスのURIにHTTPメソッドでアクセスすることにより、データ・リソースの送受信を行うモデルです。

RESTful Webサービス

現在では、以下のようなWebサービスにRESTが使用されています。（知ってました？）

Webサービスを提供するサーバーとクライアントとのインターフェースを「REST API」と言い、RESTの設計原則に基づいて提供されるサービスのことを 「RESTful サービス」と言ったりします。

RESTの設計原則

RESTの設計原則は、以下の4つに集約することができます。

それぞれ、詳しく見ていきましょう。

【原則①】アドレス指定可能なリソース

RESTでは、HTTPサーバーとクライアントでやり取りするデータを全て「リソース」という考え方で表現します。そのリソースは、URIを通じてリソースを一意に指し示すことができることをRESTの原則としています。REST APIのバージョン、どのようなリソースなのか等が一目でわかるように、URIを設計することがポイントです。

例えば、以下のようなURIの場合、どのような情報が取得できるかが一目で分かると思います。

 REST APIの例
https://progzakki.sanachan.com/api/v2/author/info

【原則②】統一されたインターフェイス

サーバーが提供するリソースの作成、取得、更新、削除といった操作は、全てHTTPメソッドを利用することを原則としています。作成「POST」、取得「GET」、更新「PUT」、削除「DELETE」のHTTPメソッドを使用します。

例えば、以下のようなREST APIは、RESTの原則を守っていないことになります。

 REST APIの悪い例
https://progzakki.sanachan.com/api/v2/author/info/get
https://progzakki.sanachan.com/api/v2/author/info/update

また、クライアントからの要求に対する処理結果は、HTTPステータスコードを使用することを原則としています。クライアントからの要求がHTTPメソッドなので、処理結果をHTTPステータスコードで返すのは自然ですね。

以下に、代表的なHTTPステータスコードをまとめておきます。

【原則③】ステートレス

ステートレスとは、「状態が無いこと」です。RESTでは、基本的にクライアント側で状態を保持し、サーバーとのやり取りで必要な情報は、全てURIとHTTPメソッドで表現することを原則としています。すなわち、HTTPサーバー側では、クライアントの状態を保持するためにセッションスコープを用いないことを意味しています。

【原則④】表現指向とハイパーリンク

リソース情報を応答する際、関連する情報はハイパーリンクとして情報に含めることができることをRESTの原則としています。そのため、リソースの表現は JSON、XML形式の場合が多いです。

RESTで設計するメリットとデメリット

メリット

デメリット

RESTfulサービスの設計手順