Grundlegende Betriebsmerkmale der ONTAP Select Deploy API
REST etabliert zwar einen gemeinsamen Satz an Technologien und Best Practices, die Details der einzelnen APIs können jedoch je nach Design variieren. Sie sollten sich mit den Details und den betrieblichen Eigenschaften der ONTAP Select Deploy API vertraut machen, bevor Sie die API verwenden.
Hypervisor-Host versus ONTAP Select Node
Ein Hypervisor-Host ist die zentrale Hardware-Plattform, die eine virtuelle ONTAP Select-Maschine hostet. Wenn eine virtuelle ONTAP Select-Maschine auf einem Hypervisor-Host bereitgestellt und aktiv ist, wird die virtuelle Maschine als ONTAP Select-Knoten betrachtet. Mit Version 3 der Deploy REST API sind die Host- und Knoten-Objekte getrennt und unterschiedlich. Dies ermöglicht eine Eins-zu-Viele-Beziehung, bei der ein oder mehrere ONTAP Select-Knoten auf demselben Hypervisor-Host ausgeführt werden können.
Objektbezeichner
Jeder Ressourceninstanz bzw. jedem Objekt wird bei der Erstellung eine eindeutige Kennung zugewiesen. Diese Kennungen sind innerhalb einer bestimmten ONTAP Select Deploy Instanz global eindeutig. Nach einem API-Aufruf, der eine neue Objektinstanz erstellt, wird der zugehörige id-Wert im location Header der HTTP-Antwort an den Aufrufer zurückgegeben. Sie können die Kennung extrahieren und bei nachfolgenden Aufrufen verwenden, um auf die Ressourceninstanz zu verweisen.
|
|
Der Inhalt und die interne Struktur der Objektbezeichner können sich jederzeit ändern. Sie sollten die Bezeichner nur bei den entsprechenden API-Aufrufen verwenden, wenn Sie auf die zugehörigen Objekte verweisen müssen. |
Anforderungskennungen
Jeder erfolgreichen API-Anfrage wird eine eindeutige Kennung zugewiesen. Die Kennung wird im request-id Header der zugehörigen HTTP-Antwort zurückgegeben. Sie können eine Anfrage-Kennung verwenden, um gemeinsam auf die Aktivitäten einer einzelnen spezifischen API-Anfrage-Antwort-Transaktion zu verweisen. Beispielsweise können Sie alle Ereignismeldungen für eine Transaktion basierend auf der Anfrage-ID abrufen.
Synchrone und asynchrone Aufrufe
Es gibt zwei Hauptmethoden, mit denen ein Server eine vom Client empfangene HTTP (Hypertext Transfer Protocol)-Anfrage ausführt:
-
Synchron: Der Server führt die Anfrage sofort aus und antwortet mit einem Statuscode von 200, 201 oder 204.
-
Asynchron Der Server akzeptiert die Anfrage und antwortet mit dem Statuscode 202. Dies bedeutet, dass der Server die Clientanfrage angenommen und einen Hintergrundprozess zur Bearbeitung gestartet hat. Ob die Anfrage erfolgreich war oder nicht, ist nicht sofort ersichtlich und muss durch weitere API-Aufrufe ermittelt werden.
Bestätigen Sie den Abschluss eines langwierigen Auftrags
Generell wird jede Operation, die lange dauern kann, asynchron mithilfe einer Hintergrundaufgabe auf dem Server verarbeitet. Mit der Deploy REST API ist jede Hintergrundaufgabe durch ein Job-Objekt verankert, das die Aufgabe verfolgt und Informationen wie den aktuellen Status bereitstellt. Ein Job-Objekt, einschließlich seiner eindeutigen Kennung, wird in der HTTP-Antwort zurückgegeben, nachdem eine Hintergrundaufgabe erstellt wurde.
Sie können das Job-Objekt direkt abfragen, um den Erfolg oder Misserfolg des zugehörigen API-Aufrufs zu ermitteln. Weitere Informationen finden Sie unter asynchrone Verarbeitung mit dem Job-Objekt.
Neben der Verwendung des Job-Objekts gibt es weitere Möglichkeiten, den Erfolg oder Misserfolg einer Anfrage zu ermitteln, darunter:
-
Ereignismeldungen Sie können alle Ereignismeldungen abrufen, die mit einem bestimmten API-Aufruf verknüpft sind, indem Sie die mit der ursprünglichen Antwort zurückgegebenen Anfrage-ID verwenden. Die Ereignismeldungen enthalten typischerweise einen Hinweis auf Erfolg oder Misserfolg und können auch beim Debuggen eines Fehlerzustands nützlich sein.
-
Ressourcenzustand oder -status Mehrere der Ressourcen verwalten einen Zustand oder Statuswert, den Sie abfragen können, um indirekt den Erfolg oder Misserfolg einer Anfrage zu bestimmen.
Sicherheit
Die Deploy-API verwendet folgende Sicherheitstechnologien:
-
Transport Layer Security: Der gesamte Netzwerkverkehr zwischen Deploy-Server und Client wird per TLS verschlüsselt. Die Verwendung des HTTP (Hypertext Transfer Protocol) über einen unverschlüsselten Kanal wird nicht unterstützt. TLS Version 1.2 wird unterstützt.
-
Die HTTP-Authentifizierung verwendet die Basic-Authentifizierung für jede API-Transaktion. Jedem Request wird ein HTTP-Header hinzugefügt, der den Benutzernamen und das Passwort als Base64-String enthält.