Skip to main content
ONTAP Select
È disponibile una versione più recente di questo prodotto.
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Caratteristiche operative di base dell'API ONTAP Select Deploy

PDF

Sebbene REST stabilisca un insieme comune di tecnologie e best practice, i dettagli di ciascuna API possono variare in base alle scelte progettuali. È necessario conoscere i dettagli e le caratteristiche operative dell'API ONTAP Select Deploy prima di utilizzarla.

Host dell'hypervisor rispetto al nodo ONTAP Select

Un host hypervisor è la piattaforma hardware principale che ospita una macchina virtuale ONTAP Select . Quando una macchina virtuale ONTAP Select viene distribuita e attiva su un host hypervisor, la macchina virtuale viene considerata un nodo ONTAP Select. Con la versione 3 dell'API REST Deploy, gli oggetti host e nodo sono separati e distinti. Ciò consente una relazione uno-a-molti, in cui uno o più nodi ONTAP Select possono essere eseguiti sullo stesso host hypervisor.

Identificatori di oggetti

A ogni istanza o oggetto di risorsa viene assegnato un identificatore univoco al momento della creazione. Questi identificatori sono globalmente univoci all'interno di una specifica istanza di ONTAP Select Deploy. Dopo aver eseguito una chiamata API che crea una nuova istanza di oggetto, il valore ID associato viene restituito al chiamante nel location Intestazione della risposta HTTP. È possibile estrarre l'identificatore e utilizzarlo nelle chiamate successive quando si fa riferimento all'istanza della risorsa.

Nota Il contenuto e la struttura interna degli identificatori degli oggetti possono cambiare in qualsiasi momento. Si consiglia di utilizzare gli identificatori solo nelle chiamate API applicabili, quando necessario, quando si fa riferimento agli oggetti associati.

Identificatori di richiesta

A ogni richiesta API andata a buon fine viene assegnato un identificatore univoco. L'identificatore viene restituito nel request-id Intestazione della risposta HTTP associata. È possibile utilizzare un identificatore di richiesta per fare riferimento collettivamente alle attività di una singola transazione API richiesta-risposta specifica. Ad esempio, è possibile recuperare tutti i messaggi di evento per una transazione in base all'ID di richiesta.

Chiamate sincrone e asincrone

Esistono due modi principali in cui un server esegue una richiesta HTTP ricevuta da un client:

  • Sincrono Il server esegue la richiesta immediatamente e risponde con un codice di stato 200, 201 o 204.

  • Asincrono: il server accetta la richiesta e risponde con un codice di stato 202. Questo indica che il server ha accettato la richiesta del client e ha avviato un'attività in background per completarla. L'esito positivo o negativo finale non è immediatamente disponibile e deve essere determinato tramite ulteriori chiamate API.

Confermare il completamento di un lavoro di lunga durata

In genere, qualsiasi operazione che può richiedere molto tempo per essere completata viene elaborata in modo asincrono utilizzando un'attività in background sul server. Con l'API REST Deploy, ogni attività in background è ancorata a un oggetto Job che tiene traccia dell'attività e fornisce informazioni, come lo stato corrente. Un oggetto Job, incluso il suo identificatore univoco, viene restituito nella risposta HTTP dopo la creazione di un'attività in background.

È possibile interrogare direttamente l'oggetto Job per determinare l'esito positivo o negativo della chiamata API associata. Per ulteriori informazioni, consultare elaborazione asincrona tramite l'oggetto Job.

Oltre all'utilizzo dell'oggetto Job, esistono altri modi per determinare il successo o il fallimento di una richiesta, tra cui:

  • Messaggi di evento È possibile recuperare tutti i messaggi di evento associati a una specifica chiamata API utilizzando l'ID della richiesta restituito con la risposta originale. I messaggi di evento in genere contengono un'indicazione di successo o fallimento e possono essere utili anche durante il debug di una condizione di errore.

  • Stato o status della risorsa Molte risorse mantengono un valore di stato o status che è possibile interrogare per determinare indirettamente il successo o il fallimento di una richiesta.

Sicurezza

L'API Deploy utilizza le seguenti tecnologie di sicurezza:

  • Transport Layer Security: tutto il traffico inviato sulla rete tra il server e il client Deploy viene crittografato tramite TLS. L'utilizzo del protocollo HTTP su un canale non crittografato non è supportato. È supportata la versione 1.2 di TLS.

  • Autenticazione HTTP: l'autenticazione di base viene utilizzata per ogni transazione API. Un'intestazione HTTP, che include nome utente e password in una stringa base64, viene aggiunta a ogni richiesta.