Características operacionais básicas da API ONTAP Select Deploy
Embora o REST estabeleça um conjunto comum de tecnologias e boas práticas, os detalhes de cada API podem variar de acordo com as escolhas de design. Você deve estar ciente dos detalhes e das características operacionais da ONTAP Select Deploy API antes de usar a API.
Host do hipervisor versus nó do ONTAP Select
Um host de hipervisor é a plataforma de hardware principal que hospeda uma máquina virtual ONTAP Select. Quando uma máquina virtual ONTAP Select é implantada e está ativa em um host de hipervisor, a máquina virtual é considerada um nó ONTAP Select. Com a versão 3 da API REST do Deploy, os objetos host e nó são separados e distintos. Isso permite um relacionamento um-para-muitos, em que um ou mais nós ONTAP Select podem ser executados no mesmo host de hipervisor.
Identificadores de objetos
Cada instância ou objeto de recurso recebe um identificador único no momento de sua criação. Esses identificadores são globalmente únicos dentro de uma instância específica do ONTAP Select Deploy. Após a emissão de uma chamada de API que cria uma nova instância de objeto, o valor do id associado é retornado ao solicitante no location header da resposta HTTP. Você pode extrair o identificador e usá-lo em chamadas subsequentes ao se referir à instância do recurso.
|
|
O conteúdo e a estrutura interna dos identificadores de objeto podem mudar a qualquer momento. Você deve usar os identificadores apenas nas chamadas de API aplicáveis, conforme necessário, ao se referir aos objetos associados. |
Identificadores de solicitação
A cada requisição de API bem-sucedida é atribuído um identificador único. Esse identificador é retornado no request-id cabeçalho da resposta HTTP associada. Você pode usar um identificador de requisição para se referir coletivamente às atividades de uma única transação de requisição-resposta da API. Por exemplo, você pode recuperar todas as mensagens de evento de uma transação com base no id da requisição.
Chamadas síncronas e assíncronas
Existem duas maneiras principais pelas quais um servidor processa uma solicitação HTTP recebida de um cliente:
-
Síncrono O servidor executa a solicitação imediatamente e responde com um código de status 200, 201 ou 204.
-
Assíncrono O servidor aceita a solicitação e responde com um código de status 202. Isso indica que o servidor aceitou a solicitação do cliente e iniciou uma tarefa em segundo plano para concluir a solicitação. O sucesso ou falha final não está disponível imediatamente e deve ser determinado por meio de chamadas de API REST adicionais.
Confirme a conclusão de um trabalho de longa duração
Geralmente, qualquer operação que possa levar muito tempo para ser concluída é processada de forma assíncrona usando uma tarefa em segundo plano no servidor. Com a Deploy API REST, cada tarefa em segundo plano é ancorada por um objeto Job que rastreia a tarefa e fornece informações, como o estado atual. Um objeto Job, incluindo seu identificador exclusivo, é retornado na resposta HTTP após a criação de uma tarefa em segundo plano.
Você pode consultar o objeto Job diretamente para determinar o sucesso ou a falha da chamada de API associada. Consulte processamento assíncrono usando o objeto Job para obter mais informações.
Além de usar o objeto Job, existem outras maneiras de determinar o sucesso ou a falha de uma solicitação, incluindo:
-
Mensagens de evento Você pode recuperar todas as mensagens de evento associadas a uma chamada de API específica usando o ID da solicitação retornado na resposta original. As mensagens de evento geralmente contêm uma indicação de sucesso ou falha e também podem ser úteis na depuração de uma condição de erro.
-
Estado ou status do recurso Vários recursos mantêm um valor de estado ou status que você pode consultar para determinar indiretamente o sucesso ou a falha de uma solicitação.
Segurança
A API de Implantação utiliza as seguintes tecnologias de segurança:
-
Transport Layer Security Todo o tráfego enviado pela rede entre o servidor Deploy e o cliente é criptografado por meio do TLS. O uso do protocolo HTTP em um canal não criptografado não é compatível. A versão 1.2 do TLS é compatível.
-
A autenticação HTTP Basic authentication é usada em todas as transações da API. Um cabeçalho HTTP, que inclui o nome de usuário e a senha em uma string base64, é adicionado a cada solicitação.