Schlüsselkonzepte für Jitterbit API Manager

Diese Seite behandelt die grundlegenden Konzepte, die du beim Arbeiten mit Jitterbit API Manager verstehen musst, einschließlich API-Typen, Sicherheitsfunktionen, die durch API-Gateways durchgesetzt werden, und der Struktur von Service-URLs.

API-Typen

In API Manager kannst du drei API-Typen erstellen und veröffentlichen. Jeder Typ interagiert innerhalb der Systemarchitektur auf einzigartige Weise mit Harmony.

Weitere Informationen zur Jitterbit-Sicherheit und Systemarchitektur findest du im Jitterbit-Sicherheits- und Architektur-Whitepaper.

Custom API

Custom APIs stellen einen Harmony-Operation zur Nutzung zur Verfügung. Um eine Custom API zu konfigurieren, musst du zunächst einen Operation in Harmony erstellen und bereitstellen. Der Operation kann ein Studio- oder Design Studio-Operation sein. Bei der Konfiguration der Custom API referenzierst du den vorhandenen Operation. API-Konsumenten rufen den Operation durch die Custom API auf und nutzen ihn. Custom APIs werden über Jitterbit-Agenten weitergeleitet (entweder Cloud-Agent-Gruppen oder Private Agents).

Funktionsweise von Custom APIs

Wenn ein API-Konsument eine Custom API aufruft, erfolgt der folgende Prozess:

1. Ein API-Konsument ruft die Custom API am Cloud-API-Gateway auf.
2. Das Cloud-API-Gateway authentifiziert die Anfrage und setzt Sicherheitsrichtlinien durch. Anschließend leitet es die Custom-API-Anfrage an den Messaging-Service weiter, der Anfragen für Agent-Gruppen weiterleitet.
3. Ein Cloud-Agent empfängt die Anfrage vom Messaging-Service.
4. Der Cloud-Agent referenziert den Custom-API-Operation, den du während der Custom-API-Konfiguration angegeben hast, und löst den bereitgestellten Operation aus.
5. Der Operation antwortet mit einer API-Payload. Diese Payload stimmt mit dem Antworttyp überein, den du während der Custom-API-Konfiguration ausgewählt hast.
6. Der Cloud-Agent leitet die API-Payload zurück an den API-Konsumenten.

Weitere Informationen zur Konfiguration einer Custom API findest du unter Custom-API-Konfiguration.

OData-Service

OData-Services stellen einen Design Studio API-Entity-Operation zur Nutzung zur Verfügung. Um einen OData-Service zu konfigurieren, musst du zunächst einen API-Entity-Operation in Harmony erstellen und bereitstellen. Bei der Konfiguration des OData-Service referenzierst du den vorhandenen API-Entity-Operation. API-Konsumenten rufen den Operation durch den OData-Service auf und nutzen ihn. OData-Services werden über Jitterbit-Agenten weitergeleitet (entweder Cloud-Agent-Gruppen oder Private Agents).

Funktionsweise von OData-Services

Wenn ein API-Konsument einen OData-Service aufruft, erfolgt der folgende Prozess:

1. Ein API-Consumer ruft den OData-Service am Private API Gateway auf.
2. Das Private API Gateway authentifiziert die Anfrage, erzwingt Sicherheitsrichtlinien und leitet die OData-Service-Anfrage weiter.
3. Der Messaging-Service empfängt die Anfrage und leitet Anfragen für Agent-Gruppen weiter.
4. Der Private Agent empfängt die Anfrage vom Messaging-Service.
5. Der Private Agent referenziert den OData-Service-Entity-Vorgang in Harmony und löst den bereitgestellten Entity-Vorgang aus.
6. Der Private Agent leitet die API-Payload aus der Vorgangsantwort durch das Private API Gateway zurück an den API-Consumer.

Informationen zum Konfigurieren eines OData-Service finden Sie unter OData-Service-Konfiguration.

Proxy-API

Proxy-APIs arbeiten mit einer bestehenden API von Drittanbietern und werden nicht wie Custom APIs oder OData-Services durch Jitterbit-Agents weitergeleitet, die einen Harmony-Vorgang zur Nutzung verfügbar machen. Die API, die Sie als Proxy verwenden, muss für das Gateway, das die API verarbeitet, entweder das Cloud API Gateway oder ein Private API Gateway, erreichbar sein:

• Cloud API Gateway: Bei Verwendung des von Jitterbit in Harmony gehosteten API Gateway muss die bestehende API öffentlich zugänglich sein, auch wenn sie geschützt ist. Die API, die Sie als Proxy verwenden möchten, kann sich nicht hinter einer Firewall befinden. Um die Cloud API Gateway-IP-Adressen auf die Whitelist zu setzen und dem Gateway Zugriff auf die API zu gewähren, die Sie als Proxy verwenden möchten, lesen Sie Allowlist-Informationen und navigieren Sie zu https://services.jitterbit für Ihre Region.

• Private API Gateway: Bei Verwendung eines Private API Gateway muss die bestehende API vom Private API Gateway erreichbar sein.

So funktionieren Proxy-APIs

Wenn ein API-Consumer eine Proxy-API aufruft, findet der folgende Prozess statt:

1. Ein API-Consumer ruft die Proxy-API am Cloud API Gateway auf.
2. Das Cloud API Gateway authentifiziert die Anfrage, erzwingt Sicherheitsrichtlinien und leitet den Proxy-API-Aufruf weiter, den es an die API des Drittanbieters sendet, die Sie als Proxy verwenden.
3. Die API des Drittanbieters antwortet mit einer API-Payload, die zum Cloud API Gateway und zurück zum API-Consumer weitergeleitet wird.
4. Das System sendet Laufzeit-Statusinformationen an die Transaktionsprotokoll-Datenbank.

Informationen zum Konfigurieren einer Proxy-API finden Sie unter Proxy-API-Konfiguration.

API-Sicherheit

Alle API-Anfragen in Jitterbit API Manager müssen durch API Gateways weitergeleitet werden, die als primäre Sicherheitsebene für Authentifizierung, Autorisierung und Zugriffskontrolle fungieren. API Manager bietet mehrere Sicherheitsfunktionen, die Sie für verschiedene Anwendungsfälle konfigurieren und verwalten können. Informationen zu Sicherheitsfunktionen in der Systemarchitektur von Jitterbit finden Sie unter Jitterbit-Sicherheit.

Sicherheitsprofile

Standardmäßig ist eine API anonym und öffentlich zugänglich, wenn Sie sie erstellen, sofern Sie kein Sicherheitsprofil im API Manager auf der Seite Sicherheitsprofile konfigurieren und der API zuweisen.

Ein API-Sicherheitsprofil regelt und sichert die API-Nutzung. Sicherheitsprofile ermöglichen es, dass eine veröffentlichte API nur von einem bestimmten API-Consumer oder einer Gruppe von Consumern genutzt wird. Sie können Sicherheitsprofile erstellen und zuweisen, wenn Sie ein Organisationsmitglied mit Administratorberechtigung sind.

Harmony-Organisationsadministratoren können verlangen, dass Sie jeder API beim Erstellen ein Sicherheitsprofil zuweisen, indem Sie eine Einstellung in den Richtlinien der Harmony-Organisation verwenden.

Authentifizierungstypen

Authentifizierungsoptionen in Sicherheitsprofilen steuern den API-Zugriff durch API-Consumer. Die folgende Tabelle zeigt die verfügbaren Authentifizierungstypen für Sicherheitsprofile:

API-Gateways als Sicherheitsüberprüfungspunkte

Sowohl das Cloud-API-Gateway als auch Private API Gateways fungieren als Sicherheitsrichtlinienpunkte in der API Manager-Architektur. An diesen Gateways führt das System die folgenden Aktionen aus:

• Authentifizierung von API-Consumern mithilfe des zugewiesenen Sicherheitsprofils
• Durchsetzung von Rate Limiting und IP-Adressbeschränkungen
• Anwendung von SSL-Verschlüsselungsanforderungen
• Protokollierung des gesamten API-Zugriffs für Sicherheitsaudits
• Blockierung nicht autorisierter Anfragen, bevor diese Backend-Systeme erreichen

Dieses Sicherheitsmodell gewährleistet konsistenten Schutz über alle API-Typen hinweg. Es bietet auch zentrale Kontrolle über API-Zugriffsrichtlinien.

Mehrere Sicherheitsprofile

Du kannst mehrere Sicherheitsprofile verwenden, um unterschiedliche Authentifizierungs- und Sicherheitsoptionen in derselben Umgebung zu nutzen, wobei jedes Profil auf eine bestimmte Gruppe von API-Consumern ausgerichtet ist.

Wenn du beispielsweise zwei Consumer-Typen (Accounting und Finance) und zwei APIs (API-Revenue und API-Budget) in einer Umgebung hast und API-Revenue für Accounting-Consumer und API-Budget für beide Accounting- und Finance-Consumer vorgesehen ist, kannst du ein einzelnes Sicherheitsprofil für Accounting-Consumer erstellen und es beiden APIs zuweisen. Anschließend kannst du ein separates Sicherheitsprofil für Finance-Consumer erstellen und es API-Budget zuweisen.

Das Ergebnis der zwei Sicherheitsprofile ist, dass Accounting-Consumer (unter Verwendung ihres Sicherheitsprofils) nur auf API-Revenue zugreifen können, und Finance-Consumer (unter Verwendung ihres separaten Sicherheitsprofils) auf entweder API-Revenue oder API-Budget zugreifen können.

Diese Sicherheitsprofilkombinationen sind zulässig:

• Du kannst mehrere Sicherheitsprofile mit Standardauthentifizierung einer einzelnen API zuweisen.
• Du kannst mehrere Sicherheitsprofile mit API-Schlüsselauthentifizierung einer einzelnen API zuweisen.
• Du kannst eine Kombination von Sicherheitsprofilen, die Standard- und API-Schlüsselauthentifizierung verwenden, einer einzelnen API zuweisen.

Jede andere Sicherheitsprofilkombination ist nicht zulässig.

Rate Limits

Jede Organisation hat zwei Kontingente, wie in der Jitterbit-Lizenzvereinbarung der Organisation angegeben. API Gateways setzen diese Limits am Eintrittspunkt durch:

1. API-Anfragen pro Monat Kontingent: Das Gesamtkontingent, das einer Organisation in einem Monat zur Verfügung steht. Alle Anfragen, die von allen APIs (in allen Umgebungen) in einem einzelnen Monat empfangen werden, werden auf dieses Limit angerechnet.

2. API-Anfragen pro Minute Kontingent: Die maximale Rate, mit der das Kontingent einer Organisation verbraucht werden kann.

Standardmäßig kann eine Umgebung oder ein Sicherheitsprofil auf das Gesamtkontingent einer Organisation für Anfragen über alle APIs innerhalb einer Minute zugreifen.

Nachdem eine Organisation ihr Kontingent für Anfragen pro Monat aufgebraucht hat, erhalten alle APIs innerhalb der Organisation eine 429 Too Many Requests-Antwort, bis sich das Kontingent am ersten Tag des folgenden Monats auf das maximale Kontingent zurückgesetzt hat.

Du kannst Rate Limits auf Umgebungs- und Sicherheitsprofilebene verwenden, um eine gemeinsam genutzte maximale Anzahl von API-Anfragen pro Minute durchzusetzen, die über alle APIs innerhalb einer Umgebung erfolgen können, denen ein Sicherheitsprofil zugewiesen ist.

Zusätzlich zu den oben genannten Limits erzwingt das von Jitterbit verwaltete Cloud-API-Gateway ein Plattform-Level-Limit von 200 API-Anfragen pro Minute pro Organisation. Anfragen, die diesen Schwellenwert überschreiten, werden von der Plattform einer Rate-Begrenzung unterzogen, die eine 429 Too Many Requests-Antwort zurückgibt. Dieses Limit gilt kollektiv für alle API-Typen, einschließlich Custom APIs, Proxy APIs und OData-Anfragen. Dieses Limit gilt nicht für Private API Gateways, bei denen der Durchsatz durch die Kapazität des Host-Servers bestimmt wird.

Vertrauenswürdige IP-Bereiche

Standardmäßig schränkt ein Sicherheitsprofil den Zugriff nicht auf einen vordefinierten IP-Adressbereich ein. Du kannst den Zugriff auf die APIs innerhalb eines Sicherheitsprofils auf Consumer von einer einzelnen IP-Adresse oder einem IP-Adressbereich während der Konfiguration des Sicherheitsprofils beschränken.

Wenn ein Consumer versucht, auf eine API mit einem Sicherheitsprofil zuzugreifen, das auf eine bestimmte IP-Adresse oder einen bestimmten Bereich beschränkt ist, prüft das API-Gateway die IP-Adresse des Consumers anhand der zulässigen Bereiche. IP-Adressen, die die Kriterien nicht erfüllen, werden abgelehnt und es wird eine Error 429-Nachricht zurückgegeben.

SSL-only-Modus

Sie können jede API so konfigurieren, dass sie SSL-Verschlüsselung verwendet. Standardmäßig unterstützt jede API sowohl HTTP- als auch HTTPS-Übertragung.

Die SSL-only-Option ermöglicht es Ihnen, HTTP-Traffic weiterzuleiten, um sicherzustellen, dass alle Kommunikation verschlüsselt ist. Die Identität der HTTPS-URL wird von Symantec Class 3 Secure Server SHA256 SSL CA überprüft. Die Verbindung zur HTTPS-URL ist mit moderner Kryptografie verschlüsselt.

Sie können die SSL-only-Option während der Konfiguration einer benutzerdefinierten API, eines OData-Dienstes oder einer Proxy-API aktivieren.

API-Logs

Für jeden Zugriff auf eine API wird das Sicherheitsprofil, das für den Zugriff auf die API verwendet wird, in einem Log aufgezeichnet. Die Seite API-Logs zeigt eine Tabelle mit allen API-Verarbeitungslogs und Debug-Logs (falls Debug-Logging aktiviert ist), um Publishern und Consumern bei der Behebung von Problemen zu helfen. Logs werden für benutzerdefinierte APIs, OData-Dienste und Proxy-APIs angezeigt, wenn sie über das Cloud-API-Gateway oder ein privates API-Gateway aufgerufen werden.

API-Service-URLs

Sie greifen auf benutzerdefinierte APIs, OData-Dienste und Proxy-APIs, die durch Jitterbit API Manager erstellt wurden, über eine API-Service-URL zu. Die Service-URL ist die URL, die zum Nutzen der API mit der konfigurierten Authentifizierungsmethode verwendet wird.

Sie können die Service-URL von einer Anwendung aus aufrufen. Wenn die API GET unterstützt, können Sie die URL in einen Webbrowser einfügen, um die API manuell zu nutzen.

Format der Service-URL

Alle API-Service-URLs folgen demselben Format. Proxy-APIs können zusätzliche Service-Pfad-Parameter haben:

<Protocol>://<Base URL>/<Environment URL Prefix>/<Version>/<Service Root>

<Protocol>://<Base URL>/<Environment URL Prefix>/<Version>/<Service Root>/<Service Path>

Service-URL-Komponenten

Die Service-URL jeder API wird automatisch aus folgenden Teilen konstruiert:

Fehlerbehebung

Weitere Informationen zur Fehlerbehebung findest du im Leitfaden zur Fehlerbehebung im API Manager:

• Fehler 429: Monatliche API-Aufrufgebühr überschritten

• Plattformebene-Ratenbegrenzung: 200 Anfragen pro Minute

• HTTP 504 Gateway Timeout