Quando você faz uma pesquisa na web por “como construir uma API”, descobri que algumas opções aparecem, mas muito poucas são guias de ponta a ponta. Isso pode ser devido à minha baixa capacidade de pesquisa na web ou porque é muito difícil construir uma API (desde o design até a produção). Qualquer pessoa que trabalhe com APIs dirá que isso pode ser uma façanha e tanto, e uma equipe de pessoas geralmente o gerencia. Portanto, criar você mesmo uma API e colocá-la em produção para que seus usuários possam começar a usá-la pode ser um desafio significativo. Vivemos em uma época feliz onde existem muitas ferramentas que tornam essa tarefa muito mais gerenciável. Com algo como o Postman, podemos criar a especificação da API, testar a especificação da API e, por fim, testar nossa API para garantir que esteja funcionando conforme o esperado. Para construir o back-end de nossa API, precisaremos de uma série de ferramentas como Flask, Heroku e outras, ou podemos optar por uma ferramenta de baixo código para construir e hospedar nossa API. Neste post, veremos o processo de construção de uma API e como esse processo pode ser mais eficiente. Processo de desenvolvimento de API O desenvolvimento de API é complexo, não há como contornar isso. Normalmente, precisamos projetar a API, codificar, testar, depurar, codificar novamente, testar um pouco mais, implantar quando estivermos prontos e depois há a manutenção aparentemente interminável. Um ciclo de vida típico de desenvolvimento de API será mais ou menos assim: Cada etapa do processo normalmente será realizada por outra ferramenta ou recurso, portanto, implementar uma API pode se tornar um grande esforço. Por exemplo, podemos optar por usar o Postman para projetar nossa API (Open API Specification) e usar algo como flask para nosso código conectar firebase ou algum banco de dados para armazenar ou recuperar nossos dados. Também podemos precisar fazer chamadas REST adicionais para outras APIs e serviços. Para testar, podemos usar o Postman novamente, mas depurar o código e todos os nossos conectores pode se tornar problemático. Para implantação, podemos optar pelo Heroku, mas depende do que nossa API exige. Para monitoramento, podemos criar nosso sistema de monitoramento ou usar algo como o Splunk. E quando precisamos manter nossa API, precisamos mergulhar em tudo isso. Você entende o que estou tentando dizer. O desenvolvimento de API é complicado. Encontrar uma maneira melhor Eu queria uma maneira de simplificar o ciclo de vida de desenvolvimento da API e desenvolver minhas APIs desde o design até a produção com apenas algumas ferramentas. Graças a ferramentas de baixo código como Linx, isso é possível. Consegui criar uma API, do design à implantação, usando apenas três ferramentas: Postman Eu usei o postman para criar minha especificação de API (baseada em YAML) e para testar minha API Linx eu usei para construir minha API, implementar a lógica, depurá-la e finalmente hospedá-la. Observação rápida: você também pode tentar criar uma API com este tutorial guiado. Linx SQL Server SQL Server foi usado para armazenar dados para minha API. Usei o banco de dados AdventureWorks2019 pré-criado e seus dados. O requerimento Optei por uma API direta que fará a manutenção dos registros do usuário. A API tem cinco métodos: Criando a especificação Criei uma especificação de API direta no Postman usando YAML que corresponde ao requisito. Postman me permitiu ver o que eu criei e forneceu informações adicionais visualmente. A criação da definição de API no Postman também beneficia a configuração dessa API para teste. Se desejar, você pode configurar os scripts de teste neste estágio. Construindo a API Agora que tenho a definição da API, o código pode ser criado. O Linx permite que você importe uma especificação OpenAPI 3.0 e gere automaticamente os eventos para cada método especificado. Eu só precisava especificar o URI e então construir a lógica. A criação da lógica de cada evento é relativamente rápida depois que o plug-in do banco de dados é instalado. Linx tem uma curva de aprendizado como toda ferramenta, mas depois que você entende como trabalhar com ela, o ritmo aumenta. Adicionei lógica e funcionalidade a cada evento para a API. Por exemplo, para o método GetAllUsers, todos nós precisamos ler o banco de dados SQL e retornar os resultados por meio do corpo da resposta. Testando a API Como a API já está configurada no Postman, foi muito fácil testar, em tempo real, como a API opera agora que a lógica foi implementada. O GIF abaixo mostra como usei o designer Linx para depurar a API REST que criei e como estou testando no modo de depuração. GIF Com a API sendo depurada no Linx, ela está sendo hospedada para que eu possa chamá-la para ver como ela se comportará quando eu implantar. Isso me permite testar e obter um resultado real de volta: Claro, também podemos adicionar scripts de teste no Postman para automatizar nosso processo de teste. Esses scripts garantirão que você receba a resposta correta. Como implantar a API Agora que a API foi projetada, desenvolvida e testada, ela precisa ser implantada. Isso pode ser uma tarefa substancial com o desenvolvimento de API tradicional, pois precisamos criar uma estratégia de implantação, descobrir onde hospedaremos o quê e garantir que o monitoramento e o registro sejam atendidos e muito mais. Minha implantação foi bastante simples. Implantei a API do Linx Designer diretamente no Linx Server. Demorou cerca de 2 minutos para que a solução fosse construída, enviada para o servidor e pronta para uso. A dificuldade de hospedar uma API é removida, pois o servidor Linx lida com isso. Ele também faz monitoramento e registro: Chamei o método GetUser com um ID incorreto para ver o que aconteceria se ocorresse um erro inesperado. O servidor registra o erro e indica em vermelho que ocorreu um erro: Consegui chamar a API do Postman novamente e o servidor dá uma indicação toda vez que a API é chamada. É certo que não adicionei nenhuma forma de segurança ou autenticação à minha API, mas essas configurações estão disponíveis no designer do Linx. Outra opção que tentei foi gerar a documentação da API no formato swagger. Isso acabou sendo muito valioso porque adicionando /swagger ao URI base, a documentação está disponível e hospedada com a própria API. Isso facilita a distribuição da documentação da API quando necessário. Empacotando Ao combinar Linx e Postman, podemos projetar, criar, documentar e hospedar APIs. Demora um pouco para se acostumar, assim como qualquer ferramenta. Como o Linx usa paradigmas e jargões de programação padrão, é fácil aprender se você estiver familiarizado com uma linguagem de programação como C#. Acho que economizamos mais tempo ao implantar e hospedar uma API com o Linx. O monitoramento e a hospedagem são feitos para você, o que significa que uma dor de cabeça substancial foi resolvida. Se o registro e o monitoramento não forem granulares o suficiente, você poderá adicionar sua funcionalidade à solução Linx. Se você quiser tentar construir uma API com Linx, você mesmo pode tentar usando (com carteiro) ou projetar primeiro (só construir) código primeiro Publicado também . aqui
