OpenAPI Schnittstelle - Mehrere Kunden mit unterschiedlichen Zugriffsrechten

[Tarrew]

Hallo zusammen,

folgende Situation: Wir schreiben aktuell mehrere Microservices, die sowohl von externen Kunden als auch internen Fachabteilungen genutzt werden.
Gemäß "API-First" Ansatz, spezifizieren wir dafür zuerst die Schnittstelle im OpenAPI Format.
Idee dahinter ist, dass wir daraus unsere Controller und Interfaces generieren, die dann konform mit der Schnittstelle sind, und diverse Kunden sich die API-Clients ebenfalls generieren können, um weniger Programmieraufwand zu haben.

Jetzt ist es so, dass es verständlicherweise verschiedene Zugriffsrechte gibt, die natürlich auch geprüft werden (OpenID Connect).
Angenommen es gibt einen Endpunkt GET /items . Diesen dürfen sowohl die interne Fachabteilung (Admins) als auch externe Kunden aufrufen.
Der Endpunkt POST /items kann entsprechend nur von der internen Fachabteilung genutzt werden.

Jetzt stellt sich mir die Frage, wie man die verschiedenen Spezifikationen am besten verwaltet.

1. Möglichkeit: Alle Operationen in eine OpenAPI-Spec
Vorteil: Controller Generierung ist sehr leicht. Die generierten Controller enthalten alle benötigten Schnittstellen-Operationen.
Nachteil: Die OpenAPI-Spec wird auch an Endkunden verteilt. Diese können dann Operationen sehen, die Sie garnicht aufrufen dürfen. Finde ich irgendwie unschön.

2. Möglichkeit: Mehrere OpenAPI-Specs für Endkunden und interne Fachabteilungen.
Vorteil: Kundengruppe sieht in ihrer Spec nur die Schnittstellenoperationen, die Sie auch nutzen können.
1. Problem: In welche der beiden Specs kommen Endpunkte, die von beiden Kundengruppen genutzt werden? Ggf. Doppelpflege vorhanden.
2. Problem: Was passiert mit der OpenAPI Generierung, wenn der gleiche Controller von zwei OpenAPI Specs generiert wird. Vermutlich wird der eine überschrieben und man kann nicht beide Specs "mergen".

3. Möglichkeit: 2 verschiedene Schnittstellen mit unterschiedlichen Requestmappings.
Vorteil: Vermutlich keine Probleme mit der Generierung aufgrund getrennter Controller.
Nachteil: 1. Problem aus (2) bleibt. In welche Spec kommen Operationen, die allgemeingültig sind. Ggf. hat man gleiche Operationen unter verschiedenen Endpunkten und wieder Doppelpflege.

4. Möglichkeit: ???

Habt ihr ähnliche Fälle oder Ideen, wie man so etwas vernünftig lösen kann?

VG

 

[mrBrown]

Mir würden zwei Möglichkeiten einfallen:

• alles in einer Spezifikation und nutzen von Tags. Aus der großen Spezifikation kann man sich dann anhand der Tags die spezifischen Spezifikationen generieren. Ob’s da Tools für gibt weiß ich nicht, kann man sich aber sonst wahrscheinlich selbst bauen.
• alles in einzelnen, kleinen Spezifikationen, und für jeden Mandanten werden alle kleinen, die für ihn relevant sind, zu einer großen gemerged.

Welches davon einfacher umsetzbar und/oder am praktikabelsten ist, muss man wahrscheinlich einmal an einem Prototypen ausprobieren.

 

[Tarrew]

Mir würden zwei Möglichkeiten einfallen:

• alles in einer Spezifikation und nutzen von Tags. Aus der großen Spezifikation kann man sich dann anhand der Tags die spezifischen Spezifikationen generieren. Ob’s da Tools für gibt weiß ich nicht, kann man sich aber sonst wahrscheinlich selbst bauen.
• alles in einzelnen, kleinen Spezifikationen, und für jeden Mandanten werden alle kleinen, die für ihn relevant sind, zu einer großen gemerged.

Welches davon einfacher umsetzbar und/oder am praktikabelsten ist, muss man wahrscheinlich einmal an einem Prototypen ausprobieren.

Danke dir für die Ideen, ich werde mal probieren, beides auszutesten 🙂