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に関してもこの仕様原則が適用されます。

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

https://qiita.com/satohiro/items/9172a7ebbbc803333bc3#%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%81%A8%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9

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

https://qiita.com/satohiro/items/9172a7ebbbc803333bc3#%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%95%E3%83%AB%E3%82%B9%E3%83%86%E3%83%BC%E3%83%88%E3%83%AC%E3%82%B9

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

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

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

#### 原則3:キャッシュ制御
RESTではサーバー側から返されたレスポンスを、
**クライアント側でキャッシュすること**が原則となっています。
この``キャッシュ``とはデータを後で利用できるように一時的に保存しておくことと認識しておいていただければ大丈夫です。
キャッシュにより、クライアント側にデータを保存し、**クライアント/サーバー間のやり取りを排除**することで
* ユーザー体験の向上
* リソース効率の向上
* 拡張性の向上

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

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

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


###### 参考:URIとURLの違い

https://ferret-plus.com/4637

##### 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の設計原則
[こちら](https://qiita.com/satohiro/private/a51078504f657abed9bf#1uri%E3%82%92%E7%94%A8%E3%81%84%E3%81%9F%E3%83%AA%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E8%AD%98%E5%88%A5)でも説明しましたが、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について解説させていただきました。
最後まで閲覧いただきありがとうございました。


# 参考

https://blog.hubspot.jp/website/api-web

https://www.ashisuto.co.jp/eai_blog/article/201712_eai_webapi.html

https://and-engineer.com/articles/Yw14sRAAACIA5tW0

https://tech.012grp.co.jp/entry/rest_api_basics

https://webtan.impress.co.jp/g/%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5

https://mynavi-job20s.jp/howto/interface.html