REST APIのグループ化とネスト

私の質問は、REST APIを集約またはグループ化するベストプラクティスについてです。多くの異なるベンダー、データソースなどがあるシナリオがあり、REST APIをグループ化することは、システムを保守可能に保つために非常に意味があると思います。

他のシステムで同じエンティティを作成するために、他の多くの（類似した）API呼び出しをトリガーする単一のAPI呼び出しがある多くのシナリオがあります。たとえば、エンティティ "user"の例：

1. フロントエンドがREST APIを呼び出す：PUT ... / user
2. 私が想定しているのは、上記の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に対応するエンティティが多数あることに注意してください。

このシナリオのベンダーは、さまざまな機能を提供しています。ただし、同じ機能を提供するベンダーが複数存在する場合があります（ユーザーは、使用したいベンダーを選択します）。簡単にするために、例の機能が

• 調達、
• 人事、
• 管理、
• 支払い。

このようなシナリオでREST APIをグループ化してネストするためのベストプラクティスは何ですか？それらをベンダーごとにグループ化するのは良い考えですか、それとも機能ごとまたは事業体ごとにグループ化する必要がありますか？URLはどのように見えますか？

私はもっ​​と論理的なグループ分けに行きます、

2つの異なるホテル予約API（AとB）と1つの支払いゲートウェイがある、ホテル予約が実行されるシステムを想像してください。

この種の状況では、従うべきいくつかのベストプラクティスは、

• サードパーティのAPIをいずれかのサービスにラップします（サードパーティのAPIを変更する場合は常に、ラッパーサービスのみを変更する必要があります）。この例では、AとBの両方のサービスに単一のインターフェイスを使用できます。
• 機能に基づいて、より高いレベルのサービスファサードを作成します（この場合、検索用に1つ、予約用に1つ）。
• これはトラブルシューティングにも役立ちます。エラーが発生した場合、単一のファサードメソッドで発生するため、プロセス全体を簡単に追跡できるためです。

答えは、質問に記載されていないいくつかの仮定に依存します。1.ベンダーまたは内部APIを変更する自由がない2.グループ化は、単一のトランザクションで実行する必要があります。つまり、APIがベンダーAPIの障害に対してどの程度厳格である必要があるか。1つのベンダーが失敗し、残りが成功した場合はどうなりますか。これはまだ成功したと思いますか、それともロールバックAPIを開始しますか（ユーザーの削除など）

想定に基づいて、ベンダーAPIなどの実装に基づいてAPIを設計することはしません。ただし、純粋に機能、つまり新しいAPIのユーザーとその要件に基づいています。