https://www.oreilly.co.jp/books/9784873116860/
The Good Partsとは
https://www.redhat.com/en/technologies/jboss-middleware/3scale
https://cloud.google.com/apigee?hl=ja
LSUDs（large set of unknown developers）と SSKDs（small set of known developers）と公開されるAPIなのか開発者しか使わないAPIなのか
1ページ 1APIコール？に思うこと
「API Strategy and Practice」における「Michele Titolo 氏と Paul Wright 氏の講演」においても「1 スクリーン 1API コール、1 セーブ 1API コール」という言葉が出てきており、これはひとつの画面を表示するためにコールするのが 1 つの API ですむようにそれに合わせた API を用意し、何らかのデータをサーバに保存する場合にも 1 回のコールですむようにそれ向けの API を用意するのがよい、ということが述べられています。
上記のように述べられてました。これに対しては僕の経験上少し違和感がある。
1ページ 1APIコールのメリット
本書にも取り上げられている通りパフォーマンスへのメリット、フロントの状態管理においては大きなメリットになり、またバックエンドの設計にもよりますが機能改修などでページごとなくなったときなども、削除しやすく依存関係が少ないので良い。
1ページ 1APIコールのデメリット
ユースケースやページごとにAPIを生やすとなると、APIが増えて管理がしにくくなる。 今はOpenAPIなどのAPI管理ツールがあるとはいえ、画面の数=APIの数となると無限に増えてしまう。 ただの僕の経験則ですが、リニューアル以外でページが減ったり、機能がケースは少ないのでAPIが減ることはほぼない。
「1ページ 1APIコール」だと、フロントエンドとバックエンド密結合になってしまい、モバイルアプリや他のアプリケーションにAPIを提供する場合などにはまたAPIをはやし続けることになる。
以前の参画したプロジェクトではRestfulなAPIを心がけて実装していたので、resouceもフロントで正規化できており、UIを載せ替えるときになってもAPIを大幅にせずに済んだ経験もあるのでケースバイケース、またはプロダクトの方針によりそう。
1ページ 1APIコールの解決策
ユースケースごとにAPIを実装するとなると、 少し複雑な画面を実装する場合、RestfulなAPIにならないので、「RestfulなAPI」と「1 スクリーン 1API コール、1 セーブ 1API コール」は共存しつつ実装していく必要になると思う。 例えば、YouTubeトップページのような画面の場合、
- おすすめの動画を取得
- おすすめのショート動画の取得
- 登録チャンネル
ざっくり見てもこの3つのリソースに対して取得しなければならない。 これを1つのWebAPIで取得することも可能ですが、おすすめの動画を取得するAPI、ショートを取得するAPI、登録チャンネルを取得するAPIと分けて実装することも可能です。 YouTubeのバックエンドはどうなってるかよくわかっていないですが、僕だったらこれをRestfulなAPIで実装しそう。そうすることでiOSやAndroidなどのモバイルアプリや他のアプリケーションにもAPIを提供しやすくなる。
ただこれを1つのAPIの責務として実装するのも良いとは思うので、この辺は今後の開発計画やプロダクトの方針によっていくのかなあと。
このどちらを実装するにしていても線引きに正解はないと思っていて、日本語では「神コントローラー」や「神API」など何の責務がわからなくなってしまうようなAPIが生まれてしまうこともあるので検討しながら実装したいところ。英語圏では"one-size-fits-all（OSFA）"という言葉があるらしい。
ストラテジックアプローチとタクティカルアプローチの違いになるのかなと思う。
少なくともページごとにAPIを実装しているので他のページでも利用するみたいなのは絶対避けたい。いくら同じでも。
これに対処しているのが現時点で（2023年）での解決策はGraphQLやBFFアーキテクチャなどが存在してるのだと思う。
2014年11月発行と少し古い書籍ですが、この問題のアプローチとして、本書の5章でもNetflixでは「オーケストレーション層」というものを実装しているらしい。
Netflix 社では OSFA のアプローチをやめ、サーバ側の汎用的な API とクライアントの間に"Client Adapter Code"を実行する層を挟み
下記の3つの記事が紹介されていたのでまとめる。
- https://netflixtechblog.com/the-netflix-dynamic-scripting-platform-78c1b18b2a74
- https://netflixtechblog.com/embracing-the-differences-inside-the-netflix-api-redesign-15fd8b3dc49d
- https://netflixtechblog.com/the-netflix-dynamic-scripting-platform-78c1b18b2a74
下記は自分用のメモです。
本の引用がほとんどのためパスワードを設定してます。