Representational State Transfer

**Representational State Transfer** (**REST、レスト**) は、（ウェブアプリケーションプログラミングインタフェース）の設計に広く採用されているアーキテクチャスタイル（設計仕様）であり、元来はウェブのような分散ハイパーメディアシステムを構築するためのソフトウェアアーキテクチャのスタイルの一つとして提唱されたものである。RESTの設計思想に準拠している状態を**RESTful**という。IBMはAIやデータサイエンスを研究するための基本設計としてRESTを掲げている。

RESTは、HTTPプロトコル規格の主要著者の一人であるがウェブについて書いた2000年の博士論文で初めて提唱され、ネットワーキングコミュニティの中ですぐに広く使われることになった。

RESTは当初アーキテクチャの原則と制約の集合を指していたが、次第にSOAPプロトコルのような複雑な抽象化を行わず、JSONやXMLとHTTPを用いた簡易なWebインタフェース全般を指す用語として拡大解釈されるようになった。その結果、現在では「ロイ・フィールディングが提唱した本来の原則に従ったシステム」と「SOAPを使わない遠隔手続き呼出し (RPC:Remote Procedure Call) スタイルのシステム」という2つの異なる意味が存在している。なお、厳密には後者のRPCスタイルはRESTの正しい実例とは言えない。

## 原則
RESTを支持する人々は、ウェブのスケーラビリティと成長は、次に述べるような、いくつかのキーとなる設計原則の結果であると論じる。

; ステートレスなクライアント/サーバプロトコル
: HTTPメッセージの一つ一つが、そのリクエスト（メッセージ）を理解するために必要な全ての情報を含む。そのため、クライアントもサーバも、メッセージ間におけるセッションの状態を記憶しておく必要がない。ただし実際には、多くのHTTPベースのアプリケーションはクッキーやその他の仕掛けを使ってセッションの状態を管理している（URLリライティングのような一部のセッション管理手法を使うシステムは、RESTfulではない）。
; すべての情報（リソース）に適用できる「よく定義された操作」のセット
: HTTP では操作（メソッド）の小さなセットが定義されている。最も重要なのは "GET"、"POST"、"PUT"、"DELETE" である。これらはデータ永続化に要求されるCRUDと比較されることがある。もっとも "POST" に関してはCRUDにはぴったり対応していない。
; リソースを一意に識別する「汎用的な構文」
: RESTfulなシステムでは、すべてのリソースはUniform Resource Identifier (URI) で表される一意的な（ユニークな）アドレスを持つ。
; アプリケーションの情報と状態遷移の両方を扱うことができる「ハイパーメディアの使用」
: RESTシステムでは、多くの場合、HTML文書またはXML文書を使う。こうした文書に情報およびその他のリソースへのリンクを含める。こうすることにより、あるRESTリソースから他のRESTリソースを参照したい場合は単にリンクを辿るだけでよい。レジストリなどの他の基盤的な機能を使う必要はない。

## リソース
REST において重要な概念は、「リソース」(情報の断片) である。個々のリソースは、グローバルな識別子 (URI) により参照することができる。リソースに対する操作は次のようにして行われる。
* ネットワークの「コンポーネント」(クライアントやサーバ) が、標準化されたインタフェース (HTTP) により通信する。
* ネットワークを介してリソースの「表現」（）を交換する（実際にはファイルがアップロード・ダウンロードされる）。
しかし実際のところこうしたリソース操作は議論の対象となっている。一部の人々には「リソース」と「表現」とを区別することは観念的すぎるとの意見がある。ただし RDFコミュニティでは、リソースと表現の区別は、一般的に行われている。

さまざまな「コネクタ」（クライアント、サーバ、キャッシュ、トンネル など）がリクエストを仲介することができる。ただしコネクタは過去のリクエストを参照せずに仲介することができなければならない。

: これは REST の原則を構成する「レイヤリング」と呼ばれる制約である。レイヤリングは、情報アーキテクチャやネットワークアーキテクチャの他の多くの部分にも見られる一般的な設計原則でもある。

こうすることで、RESTアプリケーションは、次の2つの情報を認識することで、リソースを扱うことが可能である。
* リソース識別子
* 要求されたリクエスト
アプリケーションと実際の情報を持つサーバとの間にある他のものについて意識する必要はない。つまりアプリケーションは、キャッシュやプロキシ、ゲートウェイ、ファイアウォール、トンネルなどの有無を意識する必要は無い。

ただしアプリケーションは、返された情報（表現）のフォーマットを理解できる必要がある。そのフォーマットは、多くの場合は何らかのHTMLかXMLの文書であるが、場合によっては画像やその他のコンテンツであることもある。

## REST対RPC
RESTなウェブアプリケーションは、遠隔手続き呼出し (RPC) アプリケーションとは異なる設計面のアプローチを必要とする。RPCでは、プロトコル操作（動詞）の多様性を重視する。RPCアプリケーションが定義する操作の例を次に示す。

 getUser()
 addUser()
 removeUser()
 updateUser()
 getLocation()
 addLocation()
 removeLocation()
 updateLocation()
 listUsers()
 listLocations()
 findLocation()
 findUser()

一方RESTでは、リソース（名詞）の多様性を重視する。RESTアプリケーションが定義するリソースの型の例を次に示す。

  User {}
  Location {}

それぞれのリソースは、 のような固有のURIを持つ。このリソースを扱うクライアントは標準のHTTPメソッドを使う。例えば、
* HTTP GETを使ってリソースのコピーをダウンロードする。
* 更新したコピーをHTTP PUTによりアップロードする。
* HTTP DELETEによりそのリソースの全ての表現を削除する。
なお、それぞれのリソースが固有のURIを持っているので、キャッシュ、コピー、ブックマークすることが簡単にできることに注意してほしい。HTTP POSTは一般に副作用のあるアクションに対して使われる。たとえば購入の注文を行ったり、コレクションに情報を追加したりするために使われる。 

一例として、次のようなXML形式のユーザーのデータを扱うことを考える。


```xml
<user>
 <name>Jane User</name>
 <gender>female</gender>
 <location href="http://www.example.org/locations/us/ny/new_york_city">
  New York City, NY, US
 </location>
</user>
```


ユーザーのlocation（住所）を更新するためには、RESTクライアントはまず上記のXMLデータをHTTP GETによりダウンロードする。それからXMLデータのlocationを変更して、HTTP PUTによりアップロードする。

HTTPのメソッドが、リソースを発見するための標準的なメソッドをすべて提供してはいないことに注意してほしい。

: RPCの上記の例における list*() や find*() に相当する、HTTP LISTやFINDのようなメソッドはHTTPでは規定していない。

RESTは、その代わりに、扱う対象とするコレクションや検索結果の集合を、別の型の「リソース」として扱うことで問題に対処する。アプリケーション設計者は、リソースの検索や一覧取得のために状況に応じてそのURIやURIパターンを知っておく必要がある。

いくつかの例を示す。
* というURIへのHTTP GETリクエストは、ニューヨーク各地の情報をもつXMLファイルへのリンクの一覧を返す。
* というURIへのHTTP GETリクエストは、"Michaels" の姓をもつ全てのユーザーへのリンクの一覧を返す。

RESTは、このようなアクションをどのように行うかについてのいくつかの手がかりを提供する。この手がかりは、RESTの原則を構成する制約の一つ「アプリケーション状態のエンジンとしてのハイパーメディア」から得られる。この制約から導かれる実現手段の一つは、パラメタつきのリクエストに対しては、フォーム言語（HTMLフォームなど）を使うことである。

A9.comのOpenSearchイニシアチブは、RESTを使った検索の標準化作業を行っている。具体的には、RDF、XTM、Atom、RSS（方言を含む）、リンクを扱うためのXLinkと組み合わせた簡単な構造のXML (Plain Old XML; POX) を含む一般的なフォーマットをRESTシステムで使うことにより、情報を発見するための規格の策定である。

## RESTful APIの実装
RESTful APIではXMLではなく、より軽量でJavaScriptなどと親和性の高い JSON (JavaScript Object Notation) がデファクトスタンダードとなっている。 上記のXMLの例をJSONで表現すると以下のようになる。
```json
{
  "name": "Jane User",
  "gender": "female",
  "location": {
    "name": "New York City, NY, US",
    "href": "http://www.example.org/locations/us/ny/new_york_city"
  }
}
```
RESTful APIの実践においては、HTTP リクエストメソッド（GET, POST等）に加え、HTTPステータスコードを正しく使い分けることが重要である。RPCではエラー時でも「200 OK」を返し、ボディ内にエラーメッセージを含めることがあるが、RESTではプロトコルの仕組みを使って結果を伝える。

* 200 OK: 成功（GET, PUTなど）
* 201 Created: リソースの作成成功（POST）
* 204 No Content: 成功したが返すボディがない（DELETEなど）
* 400 Bad Request: クライアントの入力ミス
* 404 Not Found: 指定されたURIにリソースが存在しない
* 405 Method Not Allowed: そのURIでは許可されていないメソッド（GETのみの場所にPOSTした等）

なおRESTfulAPIの実装においては、認証・認可の脆弱性が多く報告されているため、OAuth2やJWTなどを用いて厳格な認証・認可の仕組みを追加する必要がある。また、通信経路は必ずHTTPS (TLS) で暗号化して盗聴や改ざんを防ぐとともに、リクエストパラメータのバリデーションを徹底し、SQLインジェクションなどの攻撃や予期せぬ情報漏洩を防ぐ対策も不可欠である。

## 公開されている実装
RESTはかなり広い意味で定義されているので、広義に捉えると非常に多くの数のRESTfulアプリケーション（HTTP GETリクエストによりアクセス可能なすべてのもの）がウェブ上に存在すると考えることができる。RESTを、一般的なWebサービスやRPCスタイルとは異なるものとして狭義に捉えても、RESTは公開されたウェブ上の随所に見つけることができる。

* ブロゴスフィア――ウェブログの世界――の大部分はRESTベースである。ブログでは、他のリソースへのリンクの一覧を含むXMLファイルを（RSS 2.0、RSS 1.0、Atomフォーマットで）ダウンロードする。
* Amazon.comはデベロッパーインターフェイスを、RESTバージョンとSOAPバージョンの両方で提供している（RESTバージョンがトラフィックの大部分を占めている）。
* eBayはRESTデベロッパーインターフェイスを提供している。
* カナダ政府の"Seniors Canad On-line" プロジェクトはRESTインターフェイスを提供している（説明）。
* BloglinesはRESTデベロッパーインターフェイスを提供している。
* Yahoo!はREST デベロッパーインターフェイスを提供している。
* OpenomyはRESTベースのオンラインファイルストレージシステムである。
* Ruby on RailsにおけるURLルーティングでは、MVCデザインパターンを使うことにより、RESTfulアプリケーション設計を支援する。
* Zopeのオブジェクト出版システム。
* ASP.NETにおけるASP.NET WebAPIは、RESTfulなAPIを、通常のRPCメソッド実装とほぼ同様の簡便さで記述する事を可能とする。また、ASP.NET MVC Frameworkを使用して、従来のMVC構造を使用した実装もサポートする。

同様のものが他にも多く提供されているとみられる。

なお、上記の多くのものは完全にRESTfulというわけではない。つまり、それらは REST の全てのアーキテクチャの制約に従っているわけではない。とはいえ、どれもRESTから刺激を受けたものであり、RESTのほとんどのアーキテクチャの制約の重要性を認識している。特に統一的なインタフェースの制約についてはそうである。これらのサービスは「偶然によるRESTful」と呼ばれることがある。

## その他

## 関連項目
*人工知能
*データサイエンス
*Python
*HTML
*Plain Old XML

*Webサービス

*Ruby on Rails
*Atom (ウェブ標準)#Atom Publishing Protocol - RESTに準拠したアプリケーションプロトコル

## 脚注

## 外部リンク
* - フィールディング が REST の考え方を最初に述べた論文
*
**
*
*
*Constructing or Traversing URIs? - 「アプリケーション状態のエンジンとしてのハイパーメディア」の制約の意味を論じる記事
*Building Web Services the REST Way