API-Gateways

Allgemein

antony verwendet zwei API Gateways, um die verschiedenen Dienste unter einem Endpunkt zu vereinen. Damit haben die Clients einen zentralen Anlaufpunkt und die Details der Verteilung der Dienste wird versteckt. Um das Qualitätsanforderung Fehlertoleranz (QZ14 in https://diegroupware.atlassian.net/wiki/spaces/DEV/pages/11075594 ) zu erreichen, ist die Trennung der Dienste notwendig.

Eingesetzt wird Ocelot (GitHub - ThreeMammals/Ocelot: .NET API Gateway ), da dieser alle Anforderungen erfüllt.

Antony hat zwei verschiedene Gateways – einen WebApiGateway und einen DesktopApiGateway für die WebApp und für die DesktopClient. Die Trennung ist notwendig, da nicht alle Funktionen der DesktopApi in der WebApi sinnvoll sind. Beispielsweise ein unauthentifizierte Call um Benutzer abzurufen (für das Autocomplete im Login) wäre in der öffentlich sichtbaren API fatal. Aber auch die ArchivierungsAPI des https://diegroupware.atlassian.net/wiki/spaces/IL/pages/1678245889 hat im Web nix verloren.

Übersicht

In der folgenden Abbildung ist eine grobe Übersicht dargestellt. Oben befinden sich die beiden verschiedenen Benutzer mit dem DesktopClient und der Webapp. Die Pfeile sind der Anwendung entsprechend eingefärbt. Diese reden mit den beiden verschiedenen Gateways (DesktopApi und WebApi) über das Intranet bzw Internet. Die Kommunikation findet über Standard HTTP(s) statt.

Die Gateways nehmen die Anfragen der Clients an und leiten sie an die konfigurierten Dienste weiter. Die Antwort wird dann wieder an den Client zurückgesendet. Die Entscheidung, welcher Dienst angesprochen wird fällt auf Basis des Pfads. Beispielsweise “api/v3/mail“ wird an den MailServer geleitet.

Wie zu sehen ist, sprechen die Clients und die WebApp niemals direkt mit den Diensten. Außnahme sind nur die LegacyDienste, die noch über EICP kommunizieren (nicht eingezeichnet)