吉田真吾（@yoshidashingo）です。
川崎さんから本書をいち早くいただけたので、内容を拝読させていただき、書評にしました。
"APIファースト"を2025年に理解する意味
いまや広く"API"といえば、フロントシステムから接続するサーバーサイドのインタフェース、モバイルからモバイルバックエンドに接続するインタフェース、事業者間でデータ連携するためのインタフェースとして普及しており、あらためてその社会的意義は啓蒙するまでもないでしょう。ただし、本書ではシステムの重要な役割を担うAPIをなんとなく作ることから脱却し、一貫性をもって設計し、安全に堅牢に運用し、開発効率を向上する手法やプロセスを、Postmanを活用して具体的に解説しています。
API = RESTful ?
古くはSOAPから、GraphQL, gRPCなどAPIのプロトコル、インタフェースはさまざまありますが、本書ではもっとも普及しているRESTを主軸に、設計から運用まで基礎から丁寧に解説しています。
APIライフサイクル全体管理に利用できるPostman
Webやモバイルのユーザーインタフェースに比べて、APIの寿命は長くなる傾向があります。それはつまりAPIのインタフェース仕様はユーザーに対する『約束』であり、単なる使いやすさ以上に、そのあらかじめ決められたインタフェースの先にある機能が、全体業務の一部に組み込まれるため、後からコロコロ変えづらいという性質があるためです。（RESTに比べてGraphQLはそんなでもないだろうと言われても、まぁ程度問題かなと）
そう考えると、APIに求められる中長期的なライフサイクル管理の態度としては『使いやすくわかりやすく設計され』『正しく仕様がドキュメントとして公開されており』『安定・堅牢であることがテストで証明されている』状態で適切な範囲に公開されていることです。
これらを達成するために、Postmanは設計やドキュメント作成、テストにどう具体的に利用できるか、本書では画面キャプチャつきの手順がこまかく解説されているので、『初めてAPIを設計・公開する人』から、『あらためてAPIを堅牢にして、管理の手間を効率化したい熟練者』まで幅広く活用できます。
ディスカバリはいつも課題だ
APIもそうですが、MCPも、A2Aも、公開した機能/プロダクトを利用する側がどう見つけるかというのがいつでも課題になります。9章ではPostmanのAPIネットワークの仕組みについて解説があり、カタログ/マーケットプレイス/ポータルなど、ユーザーが自分で作ることの多い"見つけてもらう仕組み"についてオプションが提供されています。
今後もMCPやA2Aなど、プロトコル自体は定義されているが、分散されている世界の中で自分に合った他人の公開しているプロダクトを見つける仕組みについて、いつでも課題になるので、Postmanには具体的な選択肢としてそれらも仕組みの一端をになってもらえると嬉しいと思います。（欲張り）
コミュニティガイなPostman
わたしはPostmanが大好きです。APIのテスターとして昔から利用してたPostmanですが、ライフサイクル全体を管理できるようになっただけでなく、ここ4年くらいは平林さん、川崎さん、草薙さんという、いつお声がけしても快く登壇を引き受けてくださったり、RESTに限定されないAPIの活用シーンやMCPのバックエンドとしての統合に関する議論など、さまざまなトピックを議論させてもらったり、機会があればコミュニティに顔を出してくださり、それによってAPIの普及や近隣のテクノロジースタックの普及に対するコミットメントや貢献は計り知れません。
ということで、本書をたくさん買って広めて、API設計・開発・運用をあらためて学び直すことに加え、さらにAPIに支えられるたくさんのテクノロジースタックのコミュニティも間接的に応援できるという意味で、皆さんも一緒に布教しましょう。
