RESTについてまとめてみました
RESTの学習を行ったので一度まとめておきたいと思います。
参考にしたUdemy講座はこちらです
RESTとは
アメリカの学者が2000年に定義したもので、REpresentational State Transferの頭文字から取ってRESTといいます。
日本語に訳すと「分散型システムにおける設計原則群」といいます。
もう少し分かりやすくすると「設計をする上でのルール」といった意味です。
分散型システムとはクライアントとサーバーのことを指します。クライアントはサーバーにリクエストを送り、サーバーはレスポンスを返すというクライアントがトリガーとなりサーバーは受け身とされていました。
2000年頃にできた概念なので現在はその限りではありません。REST原則という分散型システムを定義するうえでの基準となる原則があり、この原則に則り作られたシステムをREST API(RESTfull API)と呼びます。
階層化システム
web API DBが多数存在する構成のシステムのことです。その中のある一つのサーバーをコンポーネントといいます。
メリットは各システムに役割を持たせることで進化と再利用が促進されます。近年でいうマイクロサービスに近い概念といえます。
デメリットはデータ処理にオーバーヘッドが発生することでユーザー（クライアント）側から見ると動きが遅く反応が悪く感じます。
コードオンデマンド
クライアントコードをダウンロードして実行できることです。
例えば、HTML、Java Scriptなど内容の更新があった時、クライアント側は自動で新しい内容を見ることができます。このようにリリース後にクライアントコードを変更できます。
メリットはリリース済みのクライアントに対して機能が追加できること、クライアント側に処理が移譲できた分、サーバーの処理が軽くなることです。
デメリットは評価環境がChrome,safariなどブラウザアプリがたくさんある分複雑になります。
統一インターフェイス
リソースの識別、表現を用いたリソース操作、自己記述メッセージ、アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)の4つの制約で成り立っています。
メリットはシステムアーキテクチャが簡素化されてわかりやすい、提供するサービスに集中でき、独自の進化ができる、HTMLという取り決めが共通なので異なるブラウザでも同じような表示ができることです。
デメリットは標準化によって効率が犠牲になり、冗長になることです。それぞれの詳細を以下に紹介します。
リソースの識別
URIを用いてサーバーに保存されたドキュメント、画像などのデータを識別できることです。URIのリソースを識別しますが、動作は含みません。
表現を用いたリソース操作
断面情報を利用してサーバー上のデータを操作することです。認証情報のようなメタデータも含みます。
リクエストを送る際に表現（認証情報などの追加情報）を付与してサーバー側にリソースの編集をお願いすること
自己記述メッセージ
データ自身がサーバーにリクエストするデータ、クライアントへのレスポンスデータのように自らのメッセージ内容をヘッダーに記述して説明しています。
アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)
レスポンスに現在の状態を踏まえたハーパーリンクが含まれていることです。2000年頃はよく見られましたが近年は減少しています。
ステートレス
リクエストが保持されず、一つ一つの会話（コンテキスト）が独立していることを指します。
メリットは単一のリクエストを見ていればよいので監視が容易なこと、障害発生したリクエストだけ回復すればよいので障害復旧が容易、リクエスト全体でサーバーのリソースを共有する必要がないのでスケールがコンパクトであることです。
デメリットは単一リクエストで完結させるためにリクエストデータに重複ができてしまい冗長であること、アプリを複数バージョン提供し、状態をクライアント側に置いておく場合はアプリ制御が複雑になってしまいます。
キャッシュ制御
クライアント側でレスポンスをキャッシュします。
メリットとしてユーザー体験、リソース効率、拡張性が向上します。
デメリットとしては古いデータを戻してしまうとそれがユーザーに表示されてしまうことがありシステムの信頼性低下につながる恐れがあります。
REST API成熟モデル
2010年に紹介されたRESTAPI設計レベルにどれだけ準拠しているかを4段階に分類したモデルのことです。
- Level0はHTTPを使ったAPIである
- Level1はリソースの概念が導入されている
- Level2はHTTPの動詞が導入されている
- Level3はHATEOASの概念が導入されていること
以上の4段階が基準となっています。
URI設計で考慮すること
URI設計では以下のことを考慮して設計します
- 短く入力しやすいこと
- 人が読んで理解できること
- 他の人に伝わらないのでversionをvのように省略しない
- 小文字で統一されていること
- 単語はハイフンでつなげて書くこと
- リソースの集合を表すので単語は複数形で書くこと
- 日本語のようなエンコードが必要な文字を使わない
- サーバー側のアーキテクチャを記入しない
- 何を指しているのかわかる単語のみを使い改造しやすくすること
- 設計はクエリパラメータ指定のみ使用するというようにルールが統一されていること
CRUD操作のURI、HTTPメソッド
URIはリソースを表しますが、HTTPメソッドは操作を表します。
メソッドの種類は
| method | 説明 |
|---|---|
| GET | リソースの取得 |
| POST | 名前が決まっていないリソースの新規登録 |
| PUT | 既存リソースの更新、名前が特定できている場合のリソースの新規登録 |
| DELETE | リソースの削除 |
これを実際に当てはめてみます。
今回は例としてmovie（映画）をリソースとして CRUD操作のURI、HTTPメソッドを定義してみます
| URI | HTTPS method | 説明 |
|---|---|---|
| /v1/api/movies | GET | 登録されている映画を全て取得 |
| /v1/api/movies | POST | 映画の新規登録 |
| /v1/movies/{id} | PUT | 既に登録されている映画情報の更新、名前が決まっている映画の新規登録 |
| /v1/movies/{id} | DELETE | 登録されている映画の削除 |
URI設計で考慮することにも書いたようにmovie（映画）はたくさん種類があるのでリソースの集合を表すのでmoviesと複数形で書きます。
また、映画は名前が決まっているはずなので新規登録は基本的にPUTを使うことになると思います。
終わりに
RESTという言葉を聞くのも初めてでしたが、サーバーの設計上必要なものでありこの設計がうまくいってないと利用するユーザーはとても使いにくくなるというだけではなく、設計後の更新作業をする上でも意味が分からないURIの意味を推測する無駄な工程ができてしまうということが分かりました。まだ設計はしたことがないですがこれからの勉強で必ず必要となる土台の部分であると思うので今後初めて設計する時は間違えて修正が大変にならないよう参考Udemy講座を含め見返して書いていきます。
