REST-API-Unterstützung für ASA r2
Die REST-API von ASA r2 basiert auf der REST-API, die mit der einheitlichen ONTAP-Persönlichkeit ausgestattet ist. Eine Reihe von Änderungen wird an die einzigartigen Merkmale und Funktionen der ASA r2-Persönlichkeit angepasst.
Typen von API-Änderungen
Zwischen der ASA r2 REST API und der einheitlichen ONTAP REST API, die mit FAS, AFF und ASA Systemen verfügbar ist, bestehen einige Unterschiede. Das Verständnis dieser Änderungen ermöglicht eine effektivere Nutzung der Online API Referenzdokumentation.
Die REST-API von ASA r2 wurde um mehrere Endpunkte erweitert, die mit Unified ONTAP nicht verfügbar sind.
Beispielsweise wurde der REST-API für ASA r2 Systeme ein neuer Block-Volume-Endpunkt hinzugefügt. Der Block-Volume-Endpunkt ermöglicht den Zugriff auf LUN- und NVMe Namespace-Objekte und eine aggregierte Ansicht der Ressourcen. Diese Funktion ist nur über die REST-API verfügbar.
Ein weiteres Beispiel: Die Endpunkte Storage-units bieten eine aggregierte Ansicht der LUNs und NVMe-Namespaces. Es gibt mehrere Endpunkte, die alle auf Basis oder abgeleitet von basieren /api/storage/storage-units. Sie sollten auch überprüfen /api/storage/luns und /api/storage/namespaces.
Mehrere mit ASA r2 verfügbare Endpunkte haben im Vergleich zu Unified ONTAP Einschränkungen, welche HTTP-Methoden verwendet werden können. Beispielsweise sind POST und DELETE nicht zulässig, wenn der Endpunkt /api/protocols/nvme/services mit ASA r2-Systemen verwendet wird.
Einige ASA r2 Endpunkt- und Methodenkombinationen unterstützen nicht alle für die einheitliche ONTAP Persönlichkeit definierten Eigenschaften. Beispielsweise werden bei Verwendung von PATCH mit dem Endpunkt /api/storage/volumes/{uuid} mehrere Eigenschaften von ASA r2 nicht unterstützt, darunter:
-
autosize.maximum -
autosize.minimum -
autosize.mode
Es gibt mehrere Änderungen, wie ASA r2 bestimmte REST-API-Anforderungen verarbeitet. So /api/storage/luns/{uuid} wird beispielsweise eine LÖSCHANFORDERUNG mit dem Endpunkt asynchron verarbeitet.
Erhöhte Sicherheit mit OAuth 2.0
OAuth 2.0 ist das Branchenstandard-Autorisierungs-Framework. Es wird verwendet, um den Zugriff auf geschützte Ressourcen basierend auf signierten Zugriffstoken einzuschränken und zu kontrollieren. OAuth 2.0 kann mit System Manager konfiguriert werden, um die Systemressourcen von ASA r2 zu schützen.
Nachdem OAuth 2.0 mit System Manager eingerichtet wurde, kann der Zugriff durch die REST-API-Clients gesteuert werden. Sie müssen zuerst ein Zugriffstoken von einem Autorisierungsserver beziehen. Der REST-Client leitet das Token dann als Inhabertoken über den Header der HTTP-Autorisierungsanforderung an das ASA r2-Cluster weiter. Weitere Informationen finden Sie unter "Authentifizierung und Autorisierung mit OAuth 2.0" .
Greifen Sie über die Swagger-Benutzeroberfläche auf die Referenzdokumentation zur ASA r2-API zu
Sie können über die Swagger-Benutzeroberfläche Ihres ASA r2-Systems auf die REST-API-Referenzdokumentation zugreifen.
Details zur REST-API finden Sie auf der Referenzdokumentationsseite von ASA r2. Als Teil davon können Sie nach dem String Plattformspezifika suchen, um Details über die ASA r2 Systemunterstützung für die API-Aufrufe und -Eigenschaften zu finden.
Sie müssen Folgendes haben:
-
Die IP-Adresse oder der Hostname der Cluster-Management-LIF des ASA r2-Systems
-
Benutzername und Passwort für ein Konto, das über eine Berechtigung für den Zugriff auf die REST-API verfügt
-
Geben Sie die URL in Ihren Browser ein und drücken Sie Enter:
https://<ip_address>/docs/api -
Melden Sie sich mit Ihrem Administratorkonto an.
Die Dokumentationsseite der ASA r2-API wird angezeigt, wobei die API-Aufrufe in den wichtigsten Ressourcenkategorien organisiert sind.
-
Um ein Beispiel eines API-Aufrufs zu sehen, der nur für ASA r2-Systeme gilt, scrollen Sie nach unten in die Kategorie SAN und klicken Sie auf GET /Storage/Storage-units.