Gruppieren und Verschachteln von REST-APIs

Meine Frage bezieht sich auf bewährte Methoden zum Aggregieren oder Gruppieren von REST-APIs. Ich habe ein Szenario, in dem es viele verschiedene Anbieter, Datenquellen usw. gibt, und ich denke, dass das Gruppieren von REST-APIs sehr sinnvoll wäre, um das System wartbar zu halten.

Ich habe viele Szenarien, in denen ein einzelner API-Aufruf viele andere (ähnliche) API-Aufrufe auslöst, um dieselbe Entität in einem anderen System zu erstellen . Zum Beispiel für eine Beispielentität "Benutzer" :

1. Front-End-Aufrufe REST-API: PUT ... / user
2. Was ich mir vorstelle, ist, dass der Code, der die obige API abhört, dann mehrere REST-PUT-Aufrufe ausführt, beispielsweise VendorA / Benutzer, VendorB / Benutzer, VendorC / Benutzer, InternalSystemA / Benutzer, InternalSystemB / Benutzer usw.

So was:

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

Beachten Sie, dass die Beispielentität nicht "Benutzer" sein muss. Es gibt viele Entitäten, die ein Gegenstück zu den Hersteller-APIs haben.

Die Anbieter in diesem Szenario bieten unterschiedliche Funktionen. Es kann jedoch mehrere Anbieter geben, die dieselbe Funktionalität bereitstellen (und der Benutzer wählt den Anbieter aus, den er verwenden möchte). Nehmen wir zur Vereinfachung an, es handelt sich um Beispielfunktionalitäten

• Beschaffung,
• Humanressourcen,
• Verwaltung,
• Zahlung.

Was ist die beste Vorgehensweise, um REST-APIs in einem solchen Szenario zu gruppieren und zu verschachteln? Ist es eine gute Idee, sie nach Lieferanten zu gruppieren, oder sollten sie funktional oder nach Geschäftseinheiten gruppiert werden? Wie würde die URL aussehen?

Ich würde mich für eine logischere Gruppierung entscheiden,

Stellen Sie sich ein System vor, in dem Hotelbuchungen durchgeführt werden, in dem zwei verschiedene Hotelreservierungs-APIs (A und B) und ein Zahlungsgateway vorhanden sind.

In einer solchen Situation wären nur wenige Best Practices zu befolgen:

• Wickeln Sie alle Drittanbieter-APIs in einen der Dienste ein (wenn sich die Drittanbieter-API ändert, muss nur der Wrapper-Dienst geändert werden). In diesem Beispiel kann eine einzelne Schnittstelle sowohl für A- als auch für B-Dienste verwendet werden.
• Erstellen Sie übergeordnete Servicefassaden basierend auf der Funktionalität (in diesem Fall eine Fassade für die Suche und eine für die Buchung).
• Dies hilft auch bei der Fehlerbehebung, da es im Fehlerfall einfach ist, den gesamten Prozess zu verfolgen, da dies in einer einzigen Fassadenmethode geschieht

Die Antwort hängt von einigen Annahmen ab, die in der Frage nicht beschrieben sind: 1. Sie haben nicht die Freiheit, den Anbieter oder die interne API zu ändern. 2. Die Gruppierung muss in einer einzelnen Transaktion durchgeführt werden. dh wie streng sollte die API gegen Hersteller-API-Fehler sein. Was passiert, wenn 1 Anbieter ausfällt und der Rest erfolgreich ist? Betrachten wir dies immer noch als Erfolg oder initiieren wir eine Rollback-API (z. B. Benutzer löschen)?

Basierend auf den Annahmen werde ich meine API nicht basierend auf der Implementierung entwerfen, z. B. mit einer Hersteller-API usw., sondern nur basierend auf der Funktionalität, dh wer Benutzer der neuen API und deren Anforderungen sind.