新しくAPIを作るにあたって、REST APIとして作るイメージはすぐに付くけどGraphQL APIでも要件にマッチするかもしれないね、という話があった。GraphQLについてはインターンでちょっと触ったことがあるけど、概念をあまり思い出せなかったので入門しておきたいと思って本を読んだ。REST APIは知ってるつもりだけど知識の再確認をしたかった。
初めてのGraphQL ―Webサービスを作って学ぶ新世代API
初めてのGraphQL ―Webサービスを作って学ぶ新世代API
- 作者:Eve Porcello,Alex Banks
- 発売日: 2019/11/13
- メディア: 単行本（ソフトカバー）
APIが人を左右するのではない… 人がAPIを左右するのだ!!*1
GraphQL APIを作るとなると、REST APIとは考え方が違うところがけっこうある。スキーマファーストでやっていく、という指針がはっきりしているのは良さそう。フィールドを指定して、関連するオブジェクトも一気に取ってくることで転送量を押さえられる、というのは魅力的に見える。
一方で、実際にAPIを運用するにあたっては負荷対策とかキャッシュ戦略について考えることになりそう。ぜんぶ POST /graphql みたいなリクエストになるので、従来のキャッシュ戦略とはまた違ったものが求められる？
負荷対策については、クエリの深さやcomplexityの概念が確立されているのでひとまずそれに乗っかるとよさそうかな。
オブジェクトのフィールドのうち、取得コストが低いものと高いものがあるときにどうするべきか、というのが気になった。低いものはオブジェクトのフィールドにしておいて、高いものは別の型にしておくとそこで実装を分けられてすっきりする？ このあたりはもうちょっと手を動かしてみると分かりそうか。
Web API: The Good Parts
- 作者:水野 貴明
- 発売日: 2014/11/21
- メディア: 大型本
趣味のWebサービスでなんとなく自分が使う用のAPIを生やしたことはあるけど、実際のAPIはどうなっているか、を知るために読んだ。over HTTPでAPIを叩くのだからHTTPの仕組みに最大限乗っかるべき、というのは確かに、と思った。ステータスコードとかHTTPヘッダとか。GitHub APIを叩いたときはクライアントサイドキャッシュが活用されていた。
LSUDs (不特定多数の開発者) 向けのAPIは一般的に作るので不要なフィールドを引っぱってくることになりがちとか、フィールドを絞り込む工夫、というのも紹介されていた。このあたりは各自で工夫しているという感じに見える。
APIの仕様を変えられるようにバージョニングすべきとか、仕様変更の戦略の例もあっておもしろかった。非互換変更でユーザーを振り回さないための取り組み、という感じ。
これからWeb APIを実装する予定がなくても読んでおくとよさそう。既存のAPIのベストプラクティスを抽出して解説してくれているし、HTTPの仕組みへの理解も深まる。
*1:帯の文より
