フロントエンドエンジニア1年生がWEB APIについて学んでみた

## はじめに
この記事は普段バックエンドエンジニアの方に作ってもらっている「WEB APIってそもそもなんだろう」という疑問から執筆しています。

「WEB API The Good Parts(水野　貴明　　著)」を参考に自分なりにまとめアウトプットしていきます。
ぜひフロントエンドエンジニアの方で同じ疑問を持っている方は読み進めてみてください。

## 対象者
この記事は下記のような人を対象にしています。

- WEB APIについて何も知らない方
- フロントエンドエンジニアでWEB APIの触りの部分しか知らない方

それでは早速アウトプットに入っていきます。

## そもそもWEB APIって何？

"Application Programming Interface"の略で、大きなデータの塊を外部から呼び出すための仕様のことを指します。

そしてWEB APIを使うと以下のような**JSON形式**でのデータ取得が可能です。

```json
[
  {
    "userId": 1,
    "id": 1,
    "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
    "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
  },
  {
    "userId": 1,
    "id": 2,
    "title": "qui est esse",
    "body": "est rerum tempore vitae\nsequi sint nihil reprehenderit dolor beatae ea dolores neque\nfugiat blanditiis voluptate porro vel nihil molestiae ut reiciendis\nqui aperiam non debitis possimus qui neque nisi nulla"
  },
  {
    "userId": 1,
    "id": 3,
    "title": "ea molestias quasi exercitationem repellat qui ipsa sit aut",
    "body": "et iusto sed quo iure\nvoluptatem occaecati omnis eligendi aut ad\nvoluptatem doloribus vel accusantium quis pariatur\nmolestiae porro eius odio et labore et velit aut"
  }
]
```

## api設計が必要になってくる6つのパターン
- 公開しているWebサービスのデータや機能のAPI公開
- 他のページに貼り付けるウィジェットの公開
- モダンなウェブアプリケーションの構築
- スマートフォンアプリケーションの開発
- ソーシャルゲームの開発
- 社内システムの連携

## SNSサービスのapi設計

|    機能     |
|-------------|
|ユーザー登録、編集|
|友達の検索、追加、削除|
|友達の間でのメッセージのやりとり|

上記のような簡単なSNSサービスがあった場合まず**ユースケース**を洗い出します。
すると以下のように必要なAPIが列挙できます。

- ユーザー登録
- ログイン
- 自分の情報の取得
- 自分の情報の更新
- ユーザー情報の取得
- ユーザーの検索
- 友達の追加
- 友達の削除
- 友達の一覧の取得
- 友達の検索
- メッセージの投稿
- 友達のメッセージの一覧の取得
- 特定の友達のメッセージの取得
- メッセージの編集
- メッセージの削除
- 友達の近況の一覧
- 特定のユーザーの近況の一覧
- 近況の投稿
- 近況の編集
- 近況の削除

## APIエンドポイントとは
「エンドポイント」という言葉自体、文脈によってさまざまな使い方をされるそうですが、WEB APIにおけるエンドポイントとは**APIにアクセスするためのURI**を意味します。

＊URI：URLとURNの総称
＊URL：Web上の住所
(例：https://github.com/)
＊URN：Web側で認識されている名前
(例：Amazonの書籍で見かける、「ISBN」から始まる英数字の羅列のようなもの)

## エンドポイントの設計
良いURIの設計の基本原則
**覚えやすく、どんな機能を持つURIなのかが一目でわかる**
だそうです。

またこれを具体化させると以下の6つになります。
- 短く入力しやすいURI
- 人間が読んで理解できるURI
- 大文字小文字が混在していないURI
- 改造しやすいURI
- サーバ側のアーキテクチャが反映されていないURI
- ルールが統一されたURI

### 短く入力しやすいURI
```
http://api.example.com/service/api/search
```

このURIはサービスの検索apiであることはわかります。
しかし同じ認識を持たせたままもっと短くすることが可能です。

```
http://api.example.com/service/search
```

### 人間が読んで理解できるURI
```
http://api.example.com/sv/u/
```

上記のようなエンドポイントは辞めましょう。
短くはなってしますが全く理解できないはず。。。

### 大文字小文字が混在していないURI
```
http://api.example.com/Users/12345
http://example.com/API/getUserName
```

上記のようなエンドポイントも良くありません。
基本的に全て小文字を使ってエンドポイントは表記します。

### 改造しやすいURI
「改造しやすいURI」とは**URIを修正して別のURIにするのが容易であること**を指します。

```:良い例
http://api.example.com/v1/items/123456
```

```:ダメな例
// id:1~300000の範囲のとき
http://api.example.com/v1/items/alpha/:id

// id:400001~500000の範囲のとき
http://api.example.com/v1/items/beta/:id

// id:500001~700000の範囲のとき
http://api.example.com/v1/items/gamma/:id

// id:700001~の範囲のとき
http://api.example.com/v1/items/delta/:id
```

上記の「ダメな例」のエンドポイントの場合、クライアント(フロント)側ではいちいちidによって場合分けをしないといけずかなり面倒なことになってしまいます。。。

### サーバ側のアーキテクチャが反映されていないURI
サーバー側のアーキテクチャとは、例えばどんなサーバソフトウェアを利用しているか、どんな言語を使って実装を行なっているか、サーバサイドのディレクトリやシステム構成がどうなっているかということを指します。

```:×良くない例
http://api.example.com/cgi-bin/get_user.php?user=100
```

上記のようなエンドポイントは「APIが恐らくPHPで書かれていて、CGIとして動作しているんだろうなぁ」というのが一目で分かってしまいます。

ただこうした情報はAPI利用者にはまったく関係ありません。むしろこういった情報はサーバーの脆弱性を突こうとしている人たちに情報を与えてしまっています。

そのためアーキテクチャの特定を容易にしてしまうのはセキュリティ的にもよろしくありません。

### ルールが統一されたURI
```:×良くない例
// 友達の情報の取得
http://api.example.com/friends?id=100

// メッセージの投稿
http://api.example.com/friend/100/message
```
上記は統一されておらずかなりみづらいと思います。
以下はどうでしょう？
```:○良い例
// 友達の情報の取得
http://api.example.com/friends/100

// メッセージの投稿
http://api.example.com/friend/100/message
```
かなり見やすくなったと思います！

## HTTPメソッドとエンドポイント
| メソッド名 | 説明 |
|----|-------------|
| GET |リソースの取得|
| POST |リソースの新規登録|
| PUT |既存リソースの更新|
| DELETE |リソースの削除|
| PATCH |リソースの一部変更|
| HEAD |リソースのメタ情報の取得|


## 最後に
フロントエンドエンジニアとして働く中でエンドポイントは全てバックエンドエンジニアが作って下さっていますが、こういった背景のもとで作られているんだと大変勉強になりました。

まだ書籍も途中なので引き続きアウトプットしていきます。

もし何かあればコメントしていただけると助かります！