REST APIについてインプットをしたので自分なりに少しまとめてみようと思います。
REAT APIとは
RESTの原則に基づいて設計されたAPI。
API:機能やデータを外部から呼び出して、利用できるために定めた規約
REST原則
- クライアント/サーバー
- ステートレス
- キャッシュ制御
- 統一インターフェース
- 階層化システム
- コードオンデマンド
クライアント/サーバー
クライアント側がトリガーで、サーバー側は受け身
ステートレス
前の状態を保存しない。
それぞれのやりとりが独立して成立する
- メリット
- 単一のリクエスト以外見る必要がないため把握が容易
- リクエスト全体でサーバーリソースを共有する必要がないのでスケールが容易
- デメリット
- 複数バージョンを同時で提供だと状態管理が複雑になる
キャッシュ制御
→ クライアントはレスポンスをキャッシュできる
キャッシュを適切に行うことで必要な情報だけリクエストすればよくなる
- メリット
- ユーザ体験の向上
- リソースの向上
- 拡張性の向上
- デメリット
- 古いデータを戻してしまうとシステムに対する信頼性の低下につながる
統一インターフェース
4つの制約
- リソースの識別
リソース
→サーバー側に保持されるデータ
例)ドキュメント、画像、人、情報、サービス、状態
URIはリソースを識別するもの(URIに動作を含まない)
- 表現を用いたリソース操作
→クライアントへ返されるレスポンスやサーバーへPOSTするデータ
断面情報を利用してサーバー上のデータを操作する
- 自己記述のメッセージ
メッセージ：サーバーへリクエストするデータ、クライアントへレスポンスするデータ
メッセージ内容が何であるか、ヘッダーに記述されている
- アプリケーション状態エンジンとしてのハイパーメディア
- メリット
- システムアークテクチャ全体が簡素化されて分かりやすい
- 提供するサービスに集中でき、独自の進化ができる
- 異なるブラウザでも同じような画面を表示できる
- デメリット
- 標準化によって効率が犠牲になる
階層化システム
→ 多層アーキテクチャ
- メリット
- 各システム(コンポーネント)に役割を決めて独立することで進化と再利用ができる
- デメリット
- データ処理にオーバーヘッドが発生(ユーザから見ると口頭が悪く見える)
コードオンデマンド
クライアントコードをダウンロードして実行できる
リリース後にクライアントコードを変更できる
例) HTML自体の更新、Javaアプレットの更新
- メリット
- リリース済みのクライアントに対して機能追加ができる
- サーバーの負荷が下がる(クライアント処理が移譲できるため)
- デメリット
- 評価環境が複雑になる