- REpresentational State Transfer の略
- Webのアーキテクチャスタイル(設計思想)の1つ
- 自分達が作るWebサービスやWebAPIは、Webを構成する1種
- Webの1部である以上、Webの設計思想であるRESTの制約に従うことによってより良くなる
- パラメータを指定する
- 特定のURLにHTTPでアクセス
- XMLで記述されたメッセージが返ってくる
- システムの状態やセッションに依存しない
- RESTの規約に従った、RESTらしいWebサービス
- RESTfulなWebサービス
- Yahoo!
- アプリケーション中のリソースが、URIで示せる
- アドレス欄に入力すれば、そのリソースを参照できる
- ステートレスにすることで、スケーラビリティが向上する
- 将来想定されるシステム規模の増大に対応可能な設計
- RESTの1番のメリットとされる部分
- 統一インターフェース
- シンプルで一貫性のある設定
- リソースへの操作はCRUDの4種類という制約
- メソッドを限定することによりプロトコルがシンプルに保たれる
- 標準的なデータフォーマット(XMLとJSON)を扱うことで、他のシステムとの連携が容易になる
- RESTに基づいたWebアプリでは、インターフェースが固定されている為、互換性の問題が発生しない
- Web上に依存する全ての情報はリソースである
- リソースは識別子(URI)を持つ
- URIを用いることでプログラムはリソースはリソースを表現する情報にアクセス出来る
- ディレクトリ構造に似たURIを定義
- リソースの状態
- 時間や条件とともに変化する可能性があるのでなるべく永続的にアクセスできるようにするべき
- リソースの意味
- 時間や条件が変化しても不変
- URIで指し示されるリソースに、GETやPOSTなどのHTTPメソッドを適応する
- HTTP1.1ではGETやPOSTなど、8個のメソッドだけが定義されている
- 代表的なHTTPのメソッドとその役割
| メソッド | 役割 |
|---|---|
| GET | リソースの取得(読み込み) |
| POST | リソースの新規作成 |
| PUT | 既存リソースの更新 |
| DELETE | リソースの削除 |
- 1番良く利用されるのは、GETとPOST
- HTMLのフォームで指定出来るメソッドが、この2つだけで制限されているため
- GETでのアクセスはリソースの内容に影響を与えない
- 新しいURIを作成するときだけPOSTを使用する
- 子リソースの作成
- リソースへのデータ追加
- 全てのWebシステムでのURIとHTTPメソッドという同じインターフェースを利用する
- このスタイルのことを統一インターンシップと呼ぶ