---
# System prepended metadata

title: Untitled

---

## 各自発表

> [name=ken3ypa]

## 「APIデザイン・パターン」メモ 
### きっかけ
- 前期はフロント・サーバーサイド両方書いていたが、後期にはよりサーバーサイド、とりわけフロント向けのAPIを書く仕事が多くなりそう
- あらためてAPI設計についての勘所を抑えておくことで、拡張性の高いAPIを作っていきたい

### 本
- https://book.mynavi.jp/ec/products/detail/id=131252
- 全部で30章、505P
- 著者：@jgeewax / https://github.com/jgeewax
    - Google でAPIデザインや決済システムを作ってる方
- Web API を構築している、またはその予定の人。API を一般に公開することを検討している場合に本書は有効、とのこと
- APIを構築するための設計原則、や、一貫性・拡張性・可用性を確保するためのパターンについて提示している

### APIのデザインパターンとは何か
- 「設計図から作る」という選択肢をソフトウェアに適用したもの


|選択肢|難易度|柔軟性|ソフトウェアで対応するもの|
|---|---|---|---|
|組み立て済のものを購入する|簡単|なし|組み立て済みのソフトウェアパッケージを使用する|
|キットから組み立てる|簡単|非常に少ない|既存のソフトウェアをカスタマイズして作る|
|設計図から作成する|中程度|ある程度|設計書から作成する|
|ゼロから構築|難しい|ほとんど|完全に専用ソフトウェアを作成する|

=> デザインパターンは「設計図から作成する」になる

### デザインパターンはなぜ重要か
- ユーザーが容易に変更可能なものを「柔軟である」、少しの変更でもだめになるものを「硬直である」と表現することがある

ここで、APIの硬直性がより問題になるのは下記のもの

- 柔軟性が硬直で
- パブリックにユーザーに公開する(たとえばユーザーから叩かれるFacebookAPI)

拡張した場合の互換性を設計時から考慮しておかないと、ユーザーがAPIを利用した際のバグのもとになる


### ケーススタディ
- メッセージの一覧を取得する
    - GET users/:user_id/messages
    - 引数として pageToken, maxPageSize, nextPageToken を考慮しておかないと、データ量が膨大になった場合に改修が困難になる
- データをエクスポートする
    - POST users/:user_id/messages/export
    - 


> [name=makicamel]

rails/rails のコードを読みたい
