In diesem Kapitel finden Sie allgemeine Richtlinien und Konvention, die Sie beim Erstellen einer API beachten müssen.
In diesem Kapitel finden Sie allgemeine Richtlinien und Konvention, die Sie beim Erstellen einer API beachten müssen.
In diesem Kapitel finden Sie Informationen zur Abarbeitung einer Anfrage an den API Server.
Bei einer Anfrage an den API Server wird geprüft, ob in der Sitzung für das jeweilige API-Projekt die primäre und gegebenenfalls sekundäre Anmeldung erfolgt ist (siehe Authentifizierung).
HINWEIS: Diese Prüfung erfolgt nicht, wenn die API-Methode der Anfrage als AllowUnauthenticated markiert ist.
Für die Zuordnung der aktuellen Sitzung wird der vom Client übermittelte Cookie imx-session-<Name des API-Projektes> ausgewertet.
Wenn ein Cookie übermittelt wird, der aber keiner im aktuellen Prozess aktiven Sitzung zugeordnet werden kann, wird mit dem im Cookie enthaltenen Sicherheitstoken eine neue Sitzung hergestellt (siehe Sitzungsstatus und Sicherheitstoken).
Liegt keine primäre Anmeldung vor, versucht der API Server über eines der aktivierten Single-Sign-On-Authentifizierungsmodule eine Datenbankverbindung herzustellen.
Kann die Anmeldung auch dann nicht hergestellt werden, wird die Bearbeitung der Anforderung abgebrochen und der HTTP-Fehlercode 500 wird an den Client übermittelt (siehe Antwortcodes).
Der API Server prüft, ob der aktuell angemeldete Benutzer berechtigt ist, die Methode auszuführen. Verfügt der Benutzer nicht über die benötigten Berechtigungen, wird die Bearbeitung abgebrochen und der HTTP-Fehlercode 500 wird an den Client übermittelt (siehe Antwortcodes).
Der API Server ruft die an der API-Methode hinterlegten Validatoren nacheinander auf. Wenn ein Fehler zurückgemeldet wird, wird die Bearbeitung abgebrochen und der HTTP-Fehlercode 400 wird an den Client übermittelt (siehe Antwortcodes).
Ermittlung der WHERE-Klausel mit internen und externen Filtern
Laden der Daten aus der Datenbank
Anreichern einer Entity mit berechneten Spalten
Eine Entity im delayed-logic-Modus kann mit einer POST-Anfrage verändert oder mit einer DELETE-Anfrage gelöscht werden. Eine Entity in diesem Modus ist zustandslos (stateless) und belegt auf dem Server nach der Abarbeitung einer Anfrage keine Ressourcen mehr.
Unterstützte HTTP-Methoden:
GET (Lesen einer Entity)
POST (Ändern einer Entity)
DELETE (Löschen einer Entity)
Eine interaktive Entity muss einmalig mit einer PUT-Anfrage erzeugt werden, und erhält danach eine eigene ID. Benutzen Sie bei nachfolgenden Anforderungen (POST oder DELETE) diese ID.
Unterstützte HTTP-Methoden:
GET (Laden einer Entity)
PUT (Erzeugen einer interaktiven Entity)
POST (Ändern einer interaktiven Entity)
DELETE (Löschen einer interaktiven Entity)
Sie können die folgenden Arten von API-Methoden definieren.
Entity-Methoden
Benutzerdefinierte Methoden
SQL-Methoden
WebSocket-Methoden
HINWEIS: Um den Zugriff auf die API einzuschränken, können Sie API-Methoden Berechtigungsgruppen zuordnen. Weitere Informationen finden Sie im One Identity Manager Handbuch zur Autorisierung und Authentifizierung.
Entity-Methoden arbeiten mit kleinen Teilen des Objektmodells, um Daten aus der Datenbank zu lesen beziehungsweise in diese zu schreiben. Wenn Sie eine Entity-Methode erstellen müssen Sie nur Tabellen- und Spaltennamen sowie gegebenenfalls eine Filterbedingung (WHERE-Klausel) angeben. Die interne Abarbeitung wird durch den API Server übernommen. Das Schema der Eingabe- und Ausgabedaten ist ebenfalls fest vorgegeben.
Beispiele zur Definition von Entity-Methoden finden Sie im SDK unter Sdk01_Basics\01-BasicQueryMethod.cs.
© 2025 One Identity LLC. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center