REST APIについてまとめてみた

はじめに

今回はREST APIについてインプットを行ったので、自身の知識整理も兼ねた記事を作成いたいしました。
RESTはモダンな技術を用いて開発を行う際には抑えて起きたい設計原則で

• 基礎を一通り学び終え、Webシステムを作ろうとしている
• 開発のプロジェクトへアサインされた

など、これから本格的な開発を行なっていかれる方が是非とも抑えておきたい知識となっております。
本記事がそういった方々に少しでもお役に立てれば嬉しいです。

WebAPI

Web APIとは

Web APIとは、
機能やデータを外部から呼び出して利用する規約または実装
のことを言います。
つまり
Web上でのデータ連携を通じて、既に出来上がっている機能を外付け実装することだと思っておいていただければ大丈夫だと思います。

有名なものとしてGoogle Map APIがあり、
Webサイトを訪れたユーザーは、目的地周辺の地図を確認したり、周辺地図を拡大／縮小するなど、まるでGoogle Mapに接続しているように操作することができます。

Web APIのメリット

1.開発の手間や時間を抑えられる

WebAPIを使用することで、既存の機能を利用できるため、一から機能を開発するよりも開発スピードや生産性を大幅に向上できます。
新機能に対して、少ない時間で対応できるため、今後発生する利用者の新しいニーズにもリアルタイムで対応できます。

2.ユーザー層を広げられる

Web APIを上手く活用することでユーザー層を広げられるメリットもあります。
たとえば、ログインSNSを導入することでそのSNSを日常的に活用しているユーザーを取り込める可能性があります。

Web APIのデメリット

API連携先に依存してしまう

Web APIを使うと、API提供企業に依存してしまう可能性があります。
提供企業がサービスを停止すると、Web APIを利用したログインや決済機能などが使えなくなってしまいます。
また、提供企業がメンテナンスなどを行う場合もその期間サービスが使えなくなるため、あらかじめユーザーに告知しないといけません。

REST APIの基本原則

REST APIとは

RESTはREpresentational(具体的な) State(状態) Transfer（転送）の頭文字をとった略称で、
一言でまとめると

「具体的に定義された情報のやり取りをするシステム設計原則」

のことで、

つまりREAT APIとは

Web APIを用いた開発設計を行う際に、プログラム間で通信を行うための約束事

ということができるでしょう。

以下で6つの原則について説明していきます。

原則1:クライアントサーバーシステム

クライアントサーバーシステムとは
手元のPC(クライアント)から送られたリクエストに対して、サーバー側がレスポンスを返すことで、その結果をクライアント側に表示するシステムのことです。
現在のWEBシステムはほとんどがこの仕様で作られており、REST APIに関してもこの仕様原則が適用されます。

詳細に関しては下記にまとめてありますので、参考までにご確認ください。

原則2:ステートレス

ステートレスとは一言でまとめると
前回までのやり取りを維持せず、それぞれ独立しているということです。
詳細な説明は下記をご覧いただければと思います。

ステートレスなプロトコルによって、サーバーはクライアントから送られてきたリクエストだけでコンテキストを理解することができます。
上記仕様により、サーバーセッション(サーバー側で状態を保持)は使用せずに、状態はすべてクライアント上に保持される形となります。

ステートレスのメリット

• 単一のリクエスト以外見る必要がないので、監視が容易
• 障害発生したリクエストだけ回復すればいいので、障害復旧が容易
• リクエスト全体でサーバーリソースを共有する必要がないので、スケールが容易

ステートレスのデメリット

• 単一のリクエストで完結させるため、リクエストデータに重複がある
• アプリを複数バージョン同時提供し、状態をクライアントに置いておくとアプリ制御が複雑になる

原則3:キャッシュ制御

RESTではサーバー側から返されたレスポンスを、
クライアント側でキャッシュすることが原則となっています。
このキャッシュとはデータを後で利用できるように一時的に保存しておくことと認識しておいていただければ大丈夫です。
キャッシュにより、クライアント側にデータを保存し、クライアント/サーバー間のやり取りを排除することで

• ユーザー体験の向上
• リソース効率の向上
• 拡張性の向上

を見込むことができます。

原則4:統一インターフェイス

インターフェイスとは「接点」「境界面」などの意味を持ち
IT分野では2つの異なる機器やシステム、ソフトウェア間で情報のやり取りがなされる際、その間をつなぐ規格や機能のことを指します。
今回に関しては「クライアント」と「サーバー」との間で、「統一」されたやり取りの方法ということができるでしょう。
REST APIでは以下4つの統一インターフェイスが取り決められています。

1.URIを用いたリソースの識別

ここでいうリソースとは「名前がつけられるあらゆるもの」で、サーバー側に保持されるデータと考えていただければ大丈夫です。
このサーバーに保存されたデータを、URIを用いて識別することが１つ目のインターフェイスです。
ここで識別するのはリソース(名前) であって動作ではないことにご注意ください。

参考:URIとURLの違い

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

クライアントに返されるレスポンスやサーバーへPOSTするデータなど、
ある通信部分におけるデータの 「断面」 を利用してサーバーを操作するというのが２つ目のインターフェイスです。
クライアントからサーバーへ編集リクエストをする際に、認証情報などの付帯情報(メタデータ)を付与します。

3.自己記述メッセージ

自己記述とはデータ自身がデータの中身を説明しているという意味で、
サーバー側から返されるレスポンスのメタ情報(ヘッダー情報)にメッセージ内容が記述されているというのが3つ目のインターフェイスです。

4.HATEOAS

レスポンスに現在の状態を踏まえて関連するハイパーリンクを含めることが4つ目のインターフェイスです。例として検索結果ページにおける「次のページ」のようなものになります。

原則5:階層化システム

階層化システムとは、サーバーを役割ごとに細かく分けて開発する多層アーキテクチャのことを言います。
よくあるWebアプリケーションの構成としてWeb、AP、DBの構成も階層化システムであり、
サーバーひとつ単位のことをコンポーネントと表現することがあります。

原則6:コードオンデマンド

コードオンデマンドとは、プログラムコードをサーバーからダウンロードし、
クライアント側でそれを実行する仕組みのことを言います。

コードオンデマンドのメリット

• クライアントに処理が委譲できるため、サーバーの負荷が下がる。
• リリース済みのクライアントに対して機能追加ができる。

コードオンデマンドのデメリット

• 多数のクライアント環境を想定する必要があるので、評価環境が複雑になる。

HTTPメソッド

REST APIではクライアント側からサーバーのリソース(データ/情報)を操作するために、
以下4つのHTTPメソッドが使われます。

HTTPメソッド	役割
GET	データを取得する
POST	データを新規作成する
PUT	データを更新する
DELETE	データを削除する

上記メソッドをサーバー側に投げかけ、その結果はRESTではJSON形式のファイルで返されます。

URIの設計原則

こちらでも説明しましたが、REST APIにおいては、サーバー側から送られてくるデータをURIを用いてデータを判別するため、その設計をする必要があります。
そのための基本原則について下記にまとめました。

1.短くシンプルで人が読んで理解できる
2.ルールが統一されている
3.単語は名詞の複数形
4.新旧のバージョン番号を含む
→仕様変更等があった際に新旧のAPIを共存させながら運用できるようにする
5.サーバーの設計仕様が反映されていない
→悪意あるユーザーに情報を与え、脆弱性を突かれないようにする

REST_APIを用いた実装例

最後にこれまで説明してきたREST APIの原則に従って、
movieをリソースにして、CRUD操作のURI、HTTPメソッドを定義してみます。

URI	HTTPメソッド	動作
/api/movies	POST	映画を作成
/api/movies	GET	映画リストの一覧を取得
/api/movies/:id	GET	特定の映画を取得
/api/movies/:id	PUT	特定の映画を更新
/api/movies/:id	DELETE	特定の映画を削除

終わりに

今回はREST APIについて解説させていただきました。
最後まで閲覧いただきありがとうございました。

参考