Skip to main content
Uma versão mais recente deste produto está disponível.
O português é fornecido por meio de tradução automática para sua conveniência. O inglês precede o português em caso de inconsistências.

Caraterísticas operacionais básicas

Colaboradores

Embora O REST estabeleça um conjunto comum de tecnologias e práticas recomendadas, os detalhes de cada API podem variar com base nas escolhas de design. Você deve estar ciente dos detalhes e das caraterísticas operacionais da API de implantação do ONTAP Select antes de usar a API.

Host de hipervisor versus nó ONTAP Select

Um hypervisor host é a plataforma de hardware principal que hospeda uma máquina virtual ONTAP Select. Quando uma máquina virtual ONTAP Select é implantada e ativa em um host de hipervisor, a máquina virtual é considerada um nó ONTAP Select. Com a versão 3 da API REST de implantação, os objetos de host e nó são separados e distintos. Isso permite uma relação um-para-muitos, em que um ou mais nós de ONTAP Select podem ser executados no mesmo host de hipervisor.

Identificadores de objeto

Cada instância ou objeto de recurso recebe um identificador exclusivo quando é criado. Esses identificadores são globalmente exclusivos em uma instância específica do ONTAP Select Deploy. Depois de emitir uma chamada de API que cria uma nova instância de objeto, o valor de id associado é retornado ao chamador no location cabeçalho da resposta HTTP. Você pode extrair o identificador e usá-lo em chamadas subsequentes quando se refere à instância de recurso.

Observação O conteúdo e a estrutura interna dos identificadores de objeto podem mudar a qualquer momento. Você só deve usar os identificadores nas chamadas de API aplicáveis conforme necessário ao se referir aos objetos associados.

Solicitar identificadores

Cada solicitação de API bem-sucedida é atribuído um identificador exclusivo. O identificador é retornado no request-id cabeçalho da resposta HTTP associada. Você pode usar um identificador de solicitação para se referir coletivamente às atividades de uma única transação de solicitação-resposta de API específica. Por exemplo, você pode recuperar todas as mensagens de evento de uma transação com base no ID de solicitação.

Chamadas síncronas e assíncronas

Há duas maneiras principais pelas quais um servidor executa 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 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 assincronamente usando uma tarefa em segundo plano no servidor. Com a API Deploy 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 depois que uma tarefa em segundo plano é criada.

Você pode consultar o objeto Job diretamente para determinar o sucesso ou falha da chamada API associada. Consulte processamento assíncrono usando o objeto Job para obter informações adicionais.

Além de usar o objeto Job, existem outras maneiras de determinar o sucesso ou falha de uma solicitação, incluindo:

  • Você pode recuperar todas as mensagens de evento associadas a uma chamada de API específica usando o ID de solicitação retornado com a resposta original. As mensagens de evento geralmente contêm uma indicação de sucesso ou falha, e também podem ser úteis ao depurar uma condição de erro.

  • Estado ou status do recurso vários dos recursos mantêm um estado ou valor de status que você pode consultar para determinar indiretamente o sucesso ou falha de uma solicitação.

Segurança

A API Deploy usa as seguintes tecnologias de segurança:

  • Segurança da camada de transporte todo o tráfego enviado pela rede entre o servidor de implantação e o cliente é criptografado por meio do TLS. O uso do protocolo HTTP em um canal não criptografado não é suportado. O TLS versão 1,2 é suportado.

  • Autenticação HTTP a autenticação básica é usada para cada transação de API. Um cabeçalho HTTP, que inclui o nome de usuário e senha em uma cadeia de carateres base64, é adicionado a cada solicitação.