はじめに
REST APIで学んだ内容について整理していきます。
RESTとは
まずREST〇〇の言葉が多く、混乱する原因にもなるので１つずつ整理していきます。
REST
REpresentational State Transferの略称。
Webサービス設計思想(ルール)の1つで、インターネット上で情報をやり取りする際のルールを定義しています。
REST原則
RESTはインターネット上で情報をやり取りする際のルールと説明しましたが、それは6つのREST原則によって成り立ちます。
-
クライアントサーバー
システムをクライアントとサーバーの2つに分ける事を推奨する考え方です。
クライアントとサーバーが独立しているため、サーバー側の変更がクライアント側に直接影響を与えることが少なくなります。
-
階層化システム
システムを複数の層に分け、それぞれが独立した機能を持つことを推奨する考え方です。
一部の層を更新または拡張しても、他の層に影響を最小限に抑えることができます。
-
コードオンデマンド
サーバー側のコードをクライアント側にダウンロードして、クライアントアプリケーションの機能拡張を推奨する考え方です。
例えばWebページに埋め込まれたJavaScriptコードはサーバーからダウンロードされ、クライアント側で実行されます。
これによりアプリケーションの振る舞いを動的に変更できます。
-
統一インターフェース
インターフェースとは何かと何かを繋ぐものです。
この原則の中で更に4つに分岐しています。- リソースの識別
URIでサーバーに保存されたリソース(データ)を一意に識別します。
例えば特定のポケモンを識別するURIはhttps://example.com/pokemons/123です。
- リソースの表現
クライアントとサーバーでやり取りされるデータを標準化されたフォーマットで表します。httpリクエストやレスポンスのボディに含まれるXMLやJSON形式のデータがフォーマットになります。
- 自己記述メッセージ
httpリクエストやhttpレスポンスに相手(リクエストならサーバー)が解釈するために必要な情報を含めます。
httpリクエストにはGETやPOSTなどのhttpメソッドの情報が入っていますし、レスポンスにはステータスコードが入ります。
- HATEOAS
httpレスポンスに現在の状態を踏まえて関連するハイパーリンクを含めます。
例えばAmazonで商品検索するリクエストに対してのレスポンスには、詳細ページへのリンク、購入ページへのリンクが含まれます。
- リソースの識別
-
ステートレス
サーバーがクライアントの状態を保持しない事を推奨する考え方です。
各リクエストは必要なすべての情報を含む必要がありますが、シンプルな設計が可能になります。
以下の記事が分かりやすかったです。
[https://yohei-y.blogspot.com/2007/10/blog-post.html]
-
キャッシュ制御
クライアント側が一度受け取ったレスポンスデータを一定期間保持する事を推奨する考え方です。同じリクエストが再度行われたときにサーバーに問い合わせることなくそのデータを再利用することができます。
RESTfull
REST原則を守っている事を指します。
REST API(RESTfullなAPI)
REST原則に従って作成(設計)されたAPIの事です。
REST APIで設計してみる
ここではmoviesをリソースとしてCRUD操作のURI、HTTPメソッドを定義してみました。
| URI | HTTP method |
|---|---|
| /movies | POST |
| /movies | GET |
| /movies/{id} | GET |
| /movies/{id} | PUT |
| /movies/{id} | DELETE |
次の観点からこの設計はREST APIであると言えます。
-
リソースの識別
URIでサーバーに保存されたリソース(movies)を一意に識別しています。 -
統一インターフェース
URIへの操作(httpメソッド)を統一しています。 -
ステートレス
PUTやDELETEでは{id}でどのmoviesリソースが対象かを指定しています(必要な情報を含んでいる)。