REST APIのグループ化とネスト
私の質問は、REST APIを集約またはグループ化するベストプラクティスについてです。多くの異なるベンダー、データソースなどが存在するシナリオがあり、REST APIをグループ化することは、システムを保守可能に保つ上で非常に意味があると思います。
単一のAPI呼び出しが他の多くの（類似した）API呼び出しをトリガーして別のシステムに同じエンティティを作成するシナリオがたくさんあります。たとえば、エンティティ「user」の例：
- フロントエンドコールREST API：PUT .../user
- 私が想定しているのは、上記のAPIをリッスンするコードが複数のREST PUT呼び出しを行って、ベンダーA /ユーザー、ベンダーB /ユーザー、ベンダーC /ユーザー、内部システムA /ユーザー、内部システムB /ユーザーなどを呼び出すことです。
このような：
+-------------------+
+--------+ PUT +-----------+ CALL | Vendor A API |
| | +-------> | user +--------> | |
| | | +-----------+ +-------------------+
| | |
| Front | PUT +--------++ PUT +-----------+ INSERT +-------------------+
| End +------> | user +------> | user +--------> | Internal System |
| | +--------++ +-----------+ +-------------------+
| | |
| | | +-----------+ CALL +-------------------+
| | +-------> | user +--------> | Vendor B API |
+--------+ PUT +-----------+ | |
+-------------------+
+ +
+---------------------------------+
Internal REST APIs
サンプルエンティティは「ユーザー」である必要はありません。ベンダーAPIに対応するエンティティが多数あることに注意してください。
このシナリオのvendorsは、異なる機能を提供します。ただし、同じ機能を提供するベンダーが複数存在する場合があります（ユーザーは、使用したいベンダーを選択します）。簡単にするために、例の機能が
- 調達、
- 人事、
- 管理、
- 支払い。
このようなシナリオでREST APIをグループ化してネストするためのベストプラクティスは何ですか？それらをベンダーごとにグループ化するのは良い考えですか、それとも機能ごとまたは事業体ごとにグループ化する必要がありますか？ URLはどのように見えますか？
私はもっと論理的なグループ分けをします
2つの異なるホテル予約API（AとB）と1つの支払いゲートウェイがある、ホテル予約が実行されるシステムを想像してください。
このような状況では、従うべきいくつかのベストプラクティスは、
- サードパーティのAPIをサービスの1つにラップします（サードパーティのAPIが変更される場合は常に、ラッパーサービスのみを変更する必要があります）。この例では、AとBの両方のサービスに単一のインターフェースを使用できます。
- 機能に基づいて、より高いレベルのサービスファサードを作成します（この場合、検索用に1つ、予約用に1つ）。
- これはトラブルシューティングにも役立ちます。エラーがある場合、単一のファサードメソッドで発生するため、プロセス全体を簡単に追跡できるためです。
答えは、質問に記載されていないいくつかの前提に依存します。1.ベンダーまたは内部APIを変更する自由がない2.グループ化は、単一のトランザクションで実行する必要があります。つまり、ベンダーAPIの失敗に対してAPIをどの程度厳格にすべきか。 1つのベンダーが失敗し、残りが成功した場合はどうなりますか。これはまだ成功したと思いますか、それともロールバックAPIを開始しますか（ユーザーの削除など）
想定に基づいて、ベンダーAPIなどの実装に基づいてAPIを設計することはしませんが、純粋に機能（つまり、新しいAPIのユーザーとその要件）に基づいて設計します。