## 各自発表 > [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 のコードを読みたい