マスタリングAPIアーキテクチャ ―モノリシックからマイクロサービスへとアーキテクチャを進化させるための実践的手法

1章

APIの設計・構築・仕様化

　APIを設計・構築する際には、多くの選択肢が提示されます。最新の技術やフレームワークでサービスを構築することは驚くほど速く実現できますが、継続性のあるアプローチをとるには、慎重に検討する必要があります。この章では、ケーススタディにおけるサービス提供者と利用者の関係をモデル化するために、RESTとRPC（Remote Procedure Call：リモートプロシージャコール）を紹介します。

　標準規格は、設計上の決定作業を短縮し、潜在的な互換性の問題を回避するのに役立ちます。ここでは、OpenAPIの仕様、チームでの実用的な利用方法、バージョン管理の重要性などを学んでいきます。

　RPC通信はスキーマを利用して指定されます。RESTアプローチと比較するため、ここではgRPCを紹介します。RESTとgRPCの両方を念頭に置き、通信をどのようにモデル化するかについて、考慮すべきさまざまな要因を検証していきます。同じサービスでRESTとRPCの両方のAPIを提供する可能性と、それが正しいかどうかについても検討します。

1.1　ケーススタディ：Attendee APIの設計

　イントロダクションでは、レガシーカンファレンスシステムからAPIアーキテクチャに移行することを決定しました。この変化の第一歩として、新しいAttendeeサービスを作成し、それに該当するAttendee APIを公開することにします。また、APIの定義も詳細化しました。効果的に設計するためには、サービス提供者と利用者の間の通信をもっと広範に考える必要があります。さらに重要な点として、サービス提供者と利用者が誰なのかということです。サービス提供者は、Attendeeチームが担当します。このチームは、次の2つの重要な関係を維持しています。 ...