REST APIを学んだ話

はじめに

今回はREST WebAPI サービス 設計を視聴したのでアウトプット記事を書いていきます。

REST APIって何？

1語ずつ意味を確認します。

REST(Representational State Transfer)

分散型システムにおける設計ルールのこと

API(Application Programming Interface)

簡単にいうと、「境界線」「接点」
異なるソフトウェアやプログラムを連携するための機能

まとめるとREST APIは
分散型システムにおける設計ルールに則った、ソフトウェアやプログラムを連携するための機能のことです。

REST原則

次にREST原則を確認しましょう。

1. クライアント/サーバー
2. 階層化システム
3. コードオンデマンド
4. 統一インターフェース
5. ステートレス
6. キャッシュ制御
7. REST API設計レベル

クライアント/サーバー

• 要約
  • よくあるネットワークベースのアプリケーションの構成
• 特徴
  • "画面(UI)” と “データ”で関心事を分離
  • クライアント側がトリガーで、サーバー側は受け身

階層化システム

• 要約
  • 多層アーキテクチャ構成
• メリット
  • 各システム（コンポーネント）に役割を決めて独立させることで進化と再利用の促進ができる
• デメリット
  • ユーザーから見ると応答が悪く見える。キャッシュを利用すると改善が見られる

コードオンデマンド

• 要約

  • クライアントコードをダウンロードして実行できることで
    リリース後にクライアントコードを変更できる

• メリット

  • リリース済みのクライアントに対して機能追加が可能
  • サーバーの負荷が下がる（クライアントに処理が移譲できる）

• デメリット

  • 評価環境が複雑になる（多数のブラウザなど…）

統一インターフェース

リソースの識別

• 要約
  リソース : 名前がつけられるもの。サーバー側に保持されるデータ(人、画像、4/1の鹿児島の天気など...)
  URIを用いてサーバーに保存されたデータを識別する。URIに動作は含まない

表現を用いたリソース操作

• 要約
  断面情報（リソース）を利用してサーバー上のデータを操作する
  クライアントからサーバーへ編集をリクエストする際、認証情報などの追加情報を付与する

自己記述メッセージ

• 要約
  • メッセージ内容がヘッダーに記述されていればOK

自己記述 : データ自身がデータの中身を説明している
メッセージ : クライアントにレスポンスするデータ

アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)

HATEOAS : (Hypermedia as the Engine of Application State)

• 要約
  • レスポンスに現在の状態を踏まえて関連するハイパーリンクが含まれている
    (検索結果ページにおける次のページなど)
• メリット
  • システムアーキテクチャ全体が簡素化されてわかりやすくなる
  • 提供するサービスに集中でき、独自の進化ができる
  • 異なるブラウザでも同じような画面を出力できる
• デメリット
  • 標準化によって効率化が犠牲になる

ステートレス

• 要約
  • サーバーはリクエストだけでコンテキストを理解できる
  • サーバーに保存されたコンテキスト情報は使わない
    （サーバーセッションは使わない）
  • 状態はクライアント上に保存される
    （リクエストに全て含める）

→リクエストに状態情報を含めることでリクエストが独立する

• メリット
  • 単一のリクエスト以外見る必要がないので、監視が容易
  • 障害発生したリクエストだけ回復すれば良いので、障害復旧が容易
  • リクエスト全体でサーバーリソースを共有する必要がないのでスケールが容易
• デメリット
  • 単一リクエストで完結させるため、リクエストデータに重複がある
  • アプリを複数バージョン同時提供し、状態をクライアントに置いておくとアプリ制御が複雑になる

キャッシュ制御

• 要約
  クライアントはレスポンスをキャッシュできる

• メリット

  • レスポンスは明示的または暗黙的にキャッシュ可能
  • キャッシュを適切に行うことでクライアント/サーバー間の通信が排除されユーザー体験の向上、リソース効率の向上、拡張性の向上が見込める

• デメリット

  • 古いデータを戻してしまうとシステムに対する信頼性の低下につながる

REST API設計レベル

• Level0
  • HTTPを使っている
  • REST APIの基本レベル
  • RPCレベルのXML通信
    (Remote Procedure Call)
• Level1
  • リソースの概念を導入
  • リソースごとにURLを分離
  • HTTPメソッドは活用できていないので、GET, POSTのみで通信
• Level2
  • HTTPの動詞を導入
  • Level1に加えてHTTPメソッドを活用
  • CRUDに対して適切なHTTPメソッドを使っている
• Level3
  • HATEOASの概念を導入
  • Level2に加えてレスポンスにリソース間の繋がりが含まれる

よく使うHTTPメソッド

HTTP method	説明
GET	リソースの取得
POST	リソースの新規登録
PUT	既存リソースの更新 / リソースの新規登録
DELETE	リソースの削除

感想

以前、自作アプリを作った時に当時のメンターの方から
「Devtoolのヘッダーにはたくさんの情報が載っているので調べてみてください。理解することで開発がスムーズになります」と言われました。

ただ、調べてうえで何を書いているのか、どんな時に使うのかが理解できていませんでした。

今回で基本は学べたと思います。以前のメンターさんが言っていたことが、少しばかり理解できた気がします。実際の開発で詰まった際に見直していきたいと考えています。