Nesta lição, mostrarei como ler e use a documentação do OpenAPI. Existem muitos tipos de sistemas de documentação para APIs REST mas o mais conhecido e mais utilizado é chamada de Especificação OpenAPI. OpenAPI foi introduzido pela primeira vez por Swagger, que é um conjunto de ferramentas de API. O padrão agora é mantido por um grupo chamado OpenAPI Initiative, que é um consórcio de especialistas no campo da tecnologia API. A Iniciativa OpenAPI publica uma especificação que determina como a documentação do OpenAPI deve parecer e funcionar. Vamos dar uma olhada em uma implementação de referência do OpenAPI, que é hospedado por Swagger. Chama-se Swagger Petstore, e é um exemplo de cenário envolvendo animais de estimação, lojas e usuários. Este formato de documentação pretende ser muito fácil para ler, abrangente e com a capacidade para testar cada API dentro da própria documentação. Os vários métodos HTTP suportados são codificados por cores. As solicitações GET são azuis, As solicitações POST são verdes, as solicitações PUT são laranja, e as solicitações DELETE são vermelhas. Embora essas cores possam ser personalizadas, esses são os padrões. Ao clicar em cada endpoint, você pode ver todos dos detalhes desse endpoint específico dentro da API. Por exemplo, parâmetros que podem ser passados para a API: corpos de solicitação de amostra, tipos de transferência de documentos suportados, como JSON ou XML, exemplos de corpos de resposta para cada tipo de código de resposta e parâmetros de consulta que podem ser passados para a API. Além disso, na parte inferior de um documento de especificação OpenAPI, você pode encontrar os modelos. Estes listariam os diferentes tipos de objetos que pode ser incluído dentro de uma resposta do servidor. Ao clicar, pode-se ver os vários nomes de atributos e tipos de dados. Vamos experimentar um desses serviços. Se clicarmos na solicitação GET para encontrar animais de estimação por ID, podemos ver que ele aceita um parâmetro, que é necessário chamado petId. É um número inteiro, o que significa que tem que ser um número inteiro. Então, vamos clicar no botão experimentar e digite um ID no campo. Vamos clicar em executar. E algumas coisas acontecem. Primeiro de tudo, a solicitação curl é mostrada. Curl é um programa de linha de comando construído na maioria dos sistemas operacionais. Permite emitir solicitações para qualquer tipo de serviço HTTP passando uma variedade de argumentos para o executável curl. Nesse caso, o URL da OpenAPI especificado era /pet/ chaveta, petId, chave de fechamento. Os nomes das variáveis mostrados entre chaves são destinados devem ser substituídos por valores reais. E os endpoints da API sempre começam com uma barra, que seria anexado ao URL raiz da API. Como podemos ver aqui, o URL raiz é https://petstore.swagger.io/v2. O v2 aqui representa a versão dois e é assim que o controle de versão da API geralmente é tratado. O -H significa cabeçalhos e, neste caso, estamos enviando um cabeçalho de aceitação simples, que informa ao servidor qual tipo de formato de documento que preferimos onde os resultados são armazenados. Em seguida, vemos a resposta que foi emitida do servidor. O código de status aqui é 200, o que significa que a solicitação foi bem-sucedida e o que temos aqui é um corpo de resposta no formato JSON e os vários campos são preenchidos com os valores que foram recuperados do servidor. Isso representará o estado deste objeto em particular neste momento. Abaixo do corpo da resposta estão os cabeçalhos de resposta. Isso é meta-informação sobre a solicitação que ajuda a fornecer mais informações sobre o pedido em si. Agora, vamos tentar testar esta API com um ID de animal de estimação inválido. A documentação do OpenAPI é capaz de validar isso e nem permitir que a solicitação seja processada. Então, em vez de colocar um valor não numérico, vamos colocar um número que é numérico mas não foi encontrado no servidor. Desta vez, nossa resposta não é 200, é 404. 404 é o código de status HTTP emitido quando um recurso não é encontrado. Os vários outros métodos HTTP codificados por cores e endpoints podem ser usados para passar informações ao servidor para alterar o estado de um objeto. Gerando documentação OpenAPI é uma operação bastante simples que pode ser executada a partir de uma variedade de ferramentas e linguagens de programação. A documentação do OpenAPI geralmente não é criada manualmente manualmente, mas é gerado automaticamente com base sobre os serviços que são prestados. Por exemplo, este documento JSON descreve a API e faria parte do código-fonte da API. Quando a API é gerada, os documentos de especificação são criados automaticamente com base sobre o que está neste arquivo, fazer documentação abrangente de qualquer API uma operação simples que se manterá atualizado automaticamente com alterações na própria API. Obrigado por assistir. Fique atento para a próxima lição onde eu vou te mostrar como emitir solicitações GET para ler o estado de objetos de APIs REST.