Agrupando e aninhando APIs REST

Minha pergunta é sobre as melhores práticas de agregação ou agrupamento de APIs REST. Eu tenho um cenário em que existem muitos fornecedores, fontes de dados etc. e acho que agrupar APIs REST faria muito sentido manter o sistema sustentável.

Eu tenho muitos cenários em que haverá uma única chamada de API acionando muitas outras chamadas de API (semelhantes) para criar a mesma entidade em outro sistema . Por exemplo, para uma entidade de exemplo "usuário" :

1. API REST de chamadas de front-end: PUT ... / user
2. O que eu imagino é que o código que escuta na API acima fará várias chamadas REST PUT, digamos vendorA / user, vendorB / user, vendorC / user, internalSystemA / user, internalSystemB / user, etc.

Como isso:

                                                            +-------------------+              
+--------+                   PUT     +-----------+  CALL    | Vendor A API      |              
|        |                 +-------> | user      +--------> |                   |              
|        |                 |         +-----------+          +-------------------+              
|        |                 |                                                                   
| Front  | PUT    +--------++  PUT   +-----------+  INSERT  +-------------------+              
| End    +------> | user    +------> | user      +--------> | Internal System   |              
|        |        +--------++        +-----------+          +-------------------+              
|        |                 |                                                                   
|        |                 |         +-----------+  CALL    +-------------------+              
|        |                 +-------> | user      +--------> | Vendor B API      |              
+--------+                   PUT     +-----------+          |                   |              
                                                            +-------------------+             
                 +                                 +                                           
                 +---------------------------------+                                           
                         Internal REST APIs                                                    

Observe que a entidade de exemplo não precisa ser "usuário", há muitas entidades que terão uma contrapartida nas APIs do fornecedor.

Os fornecedores neste cenário fornecem funcionalidade diferente. Mas pode haver vários fornecedores que fornecem a mesma funcionalidade (e o usuário escolhe o fornecedor que deseja usar). Para simplificar, digamos que as funcionalidades de exemplo são

• Compras,
• Recursos humanos,
• Gestão,
• Forma de pagamento.

Qual é a melhor prática para agrupar e aninhar APIs REST nesse cenário? É uma boa ideia agrupá-los por fornecedor ou eles devem ser agrupados em função ou por entidade comercial? Como seria o URL?

Eu iria para um agrupamento mais lógico,

Imagine um sistema em que as reservas de hotéis sejam realizadas, onde existem 2 APIs de reserva de hotéis diferentes (A e B) e um gateway de pagamento.

Nesse tipo de situação, poucas práticas recomendadas a seguir seriam,

• Agrupe qualquer API de terceiros em um dos serviços (sempre que a API de terceiros for alterada, é necessário alterar o serviço de wrapper), neste exemplo, a interface única pode ser usada para os serviços A e B.
• Crie fachadas de serviço de nível superior com base na funcionalidade (nesse caso, uma fachada para pesquisa e outra para reserva)
• Isso também ajudará a solucionar problemas, porque, se houver um erro, seria fácil rastrear todo o processo, pois isso acontece em um único método de fachada

A resposta depende de algumas suposições não descritas na pergunta: 1. Você não tem a liberdade de alterar o fornecedor ou a API interna 2. O agrupamento deve ser executado em uma única transação. ou seja, quão rigorosa a API deve ser contra falhas na API do fornecedor. O que acontece se um fornecedor falhar e o resto for bem-sucedido. Ainda consideramos isso um sucesso ou iniciamos uma API de reversão (por exemplo, excluir usuário)

Com base nas suposições, não projetarei minha API com base na implementação, como ter uma API de fornecedor etc., mas puramente baseada na funcionalidade, ou seja, quem é usuário da nova API e seus requisitos.