はじめに
今回はWeb API開発での設計手法であるREST APIについて学習しましたので、自分なりにまとめていきます。
RESTとは
まず、そもそもRESTって何でしょうか？
RESTとは「Representational State Transfer」の略になります。
分散型システムにおける設計原則や制約、という意味で使われています。
Roy Fielding氏によって提唱されました。
この設計原則に従っていることをRESTfulと言ったり、その設計をRESTfulな設計と言います。
同様に、REST APIというのは、REST原則に従って設計されたWeb APIになります。
では、その設計原則を確認していきましょう。
REST原則
以下の6つを紹介します。
クライアントとサーバーの分離
クライアントにUI、サーバーにリソースを配置し、関心ごとを分離させます。
階層化システム
Webサーバー、APサーバー、DBサーバーというように多層構成のアーキテクチャにします。
一つのサーバーをコンポーネントと捉え、一つの層として独立させます。
これによりスケーラビリティの向上、アクセス集中時の負荷分散などが見込めます。
一方で、データ処理にオーバーヘッドが発生します。
コードオンデマンド
サーバー側からクライアント側へJavaScriptなどのコードを送り、それをクライアント側が実行することができます。
リリース済みのクライアントに対して、機能追加することができたり、クライアント側に処理を委譲することで、サーバー側の負荷を減らすことができます。
統一インターフェース
以下の4つの制約があります。
1. リソースの識別
リソースとはサーバー側に保持されているあらゆるデータのことになります。
URIを用いてリソースを識別します。
2. 表現を用いたリソース操作
表現とはリソースのある断面のことです。
XMLやJSONのフォーマットでデータをやり取りします。
3. 自己記述メッセージ
自己記述とはデータ自身がデータを説明することで、メッセージとはサーバーへリクエストするデータ、クライアントへレスポンスするデータなどです。
リクエストやレスポンスのヘッダー情報を見れば、内容がすぐ理解できます。
4. HATEOAS
レスポンスに現在の情報を踏まえた関連するハイパーリンクを含めることです。
いわゆる「次のページ」のことです。
ステートレス
サーバーはリクエストだけでコンテキストを理解できるようにします。
サーバーに保存されたコンテキストは使わずに、状態はクライアント上に保存して、リクエストに状態情報を含めます。
これにより、リクエストが独立して処理できます。
リクエストが独立するので、複数のサーバーに分散しても問題なくリクエストを処理できるようになり、スケーラビリティが向上します。
キャッシュ制御
クライアントはレスポンスをキャッシュできるようにします。
キャッシュすることで、クライアントとサーバー間の通信が排除され、ユーザー体験の向上やリソースの効率化ができます。
つまり、必要な情報だけやり取りできるようにします。
REST API成熟度モデル
Leonard Richardson氏によりREST API成熟度モデルが提唱されています。
これにより、どのくらいRESTfulな設計なのか確認できます。
一般的なWebサービスはLEVEL2が多いようです。
LEVEL 0：HTTPを使う
REST APIの基本レベルで、RPCスタイルのXML通信。
HTTPリクエストを使ってRPCを実行。
LEVEL 1：リソースの概念
リソースごとにURIを分離する。
URIでリソースを表す。
GETかPOSTしか使わない。
LEVEL 2：HTTPメソッドの適切な利用
HTTPメソッドが適切に使われている。
リソースに対して、各メソッド(POST, PUT, GET, DELETE)でCRUD操作を実現。
LEVEL 3：HATEOASの導入
レスポンスに関連するリソースのURLを含む。
URIの設計
REST APIでは、リソースをURIで識別します。
URI設計時には以下を考慮して設定していきます。
短く入力しやすい
シンプルで覚えやすい、冗長でないものにする。
単語はハイフンで繋ぐ
アンダースコアで単語を繋がず、ハイフンで繋ぐ。
しかし、そもそも単語を連結しないようにURIを見直すこと。
単語は複数形
リソースの集合をURIで表しているので、複数形にする。
エンコードを必要とする文字を使わない
例えば、以下のページのようにURLに日本語文字が入っているとエンコードされて冗長で理解できないものになる。
そうならないように英単語でURIを設計する。
サーバー側のアーキテクチャを反映しない
悪意あるユーザーに脆弱性を突かれる可能性があるため、反映させない。
改造しやすい
システム依存の設計は特定の人しか意味が理解できない。
alpha, betaなどの表現は使わない。
ルールが統一されている
片方はクエリパラメータなのに、一方はパスパラメータにはしない
→ルールを統一して設計間違いを防ぐ。
HTTPメソッド
REST APIでは、HTTPメソッドを利用してリソースに対してCRUD操作を行います。
主要なメソッドを説明します。
POST
リソース名不定で新規登録
CREATEにあたります。
GET
リソースの取得
READにあたります。
例えば、GET /v1/users/123 HTTP/1.1のようにしてリソースに対して操作を行います。
PUT
リソースの更新、リソース名が決まっていたら新規登録
UPDATEにあたります。
DELETE
リソースの削除
DELETEにあたります。
まとめ
RESTの設計原則はシンプルでスケーラビリティが高く、キャッシュ等によるパフォーマンス向上が見込めます。
URIによるリソースの識別や、HTTPメソッドでリソースを操作するという統一されたインターフェースで開発者にとってもシンプルで理解しやすいものになっています。
終わりに
今回はデメリット部分についてあまり掘り下げなかったのですが、API開発の設計手法であるGraphQLを学ぶ時には双方のメリット、デメリットを詳しく調べていきたいですね。
参考