O que é o ciclo de vida da API?

APIs são conjuntos de regras ou protocolos que permitem que aplicações de software se comuniquem entre si para trocar dados, recursos e funcionalidades.Existe um ciclo de vida do produtor de APIs, focado na criação e distribuição de APIs, e um ciclo de vida do consumidor de APIs, centrado no uso da API do ponto de vista do consumidor. Este artigo se concentra no ciclo de vida do produtor de APIs.

Não existe um ciclo de vida do produtor de APIs universal. Você pode ver diferentes variações de diferentes fontes, mas o ciclo de vida geralmente inclui as seguintes etapas: planejar, projetar, desenvolver, testar, implementar, monitorar e desativar.

As plataformas de gerenciamento de API costumam ser usadas para ajudar a organizar os esforços em um ciclo de vida da API e para centralizar a estratégia, a governança, a documentação e os diretórios de API em um ambiente de TI. Muitas plataformas incluem recursos avançados de análise de dados e ferramentas para a descoberta e monetização de APIs que ajudam as organizações a obter o máximo de suas APIs.

A análise e a compreensão de todo o ciclo de vida da API ajuda as equipes de desenvolvimento a alocar recursos de forma mais eficiente, criar cronogramas realistas de entrega, manter todos os stakeholders informados durante todo o processo e garantir que as APIs atendam aos requisitos de negócios. Essencialmente, um ciclo de vida bem planejado e executado ajuda a fornecer APIs seguras e de alto desempenho, além de uma experiência de usuário mais robusta.

O gerenciamento do ciclo de vida da API de ponta a ponta compreende várias etapas importantes, começando com o planejamento preliminar e terminando, muitas vezes, mas nem sempre, com a desativação ou substituição. Como exemplo, vamos considerar uma empresa de software que decide criar uma API para sincronizar seus dados de clientes com ferramentas de negócios, como chamados de suporte, sistemas de contabilidade, plataformas de gerenciamento de projetos e muito mais.

A criação de uma API começa com a resposta a algumas perguntas fundamentais: por que essa API é necessária, para quem ela se destina, como será usada e como o sucesso será medido?

A especificidade do objetivo do projeto de API pode ajudar a esclarecer quais recursos e funcionalidades o projeto de API precisa ter. No exemplo de desenvolvimento de software, o objetivo da API é garantir que os dados do cliente possam migrar sem dificuldades entre as aplicações e plataformas que a empresa usa ou planeja usar.

Nesta fase de planejamento, as organizações:

• Avaliam os possíveis benefícios comerciais da API
• Descrevem como essa API atenderá às necessidades comerciais
• Certificam-se de que não haja APIs existentes ou outros produtos disponíveis em mercados de integração nativa que possam fazer o que é necessário (basicamente, confirmar que a criação dessa API é necessária)
• Definem claramente quais aplicações e plataformas dependerão da API e como a API se integrará aos fluxos de trabalho existentes.

Em seguida, a equipe deve discutir os possíveis usuários e casos de uso. É exclusivamente para uso interno? Quais equipes usarão essa API e para quê? Há questões de segurança que devem ser abordadas nas fases de projeto e desenvolvimento? E, o mais importante, quem será responsável por cada fase da produção da API?

Definir um cronograma para a conclusão do projeto ajuda a garantir que ele permaneça dentro do orçamento. É importante ressaltar que os cronogramas devem ser realistas e flexíveis.

As equipes responderão a perguntas como: há alguma data específica, como uma data de lançamento de nova funcionalidade, que deve ser cumprida? Há equipes de segurança ou conformidade legal ou outras partes interessadas que precisam assinar antes que essa API possa ser implementada?

Onde a documentação e outras informações sobre a API serão armazenadas e disponibilizadas para os desenvolvedores e usuários? Onde as alterações de código serão rastreadas e armazenadas?

Responder a esses tipos de perguntas desde o início ajuda a definir um plano claro para o restante do ciclo de vida.

Enquanto a etapa de planejamento descreve o resultado desejado, a etapa de projeto define como a equipe planeja chegar lá. Durante todo o processo de projeto, a equipe de projeto da API decide como a API deve ser criada para atender aos requisitos detalhados na fase de planejamento.

A equipe deve tomar decisões de projeto sobre o protocolo e o estilo de arquitetura que a API usará. Essa decisão pode ser baseada na arquitetura de API existente na organização ou nos casos de uso pretendidos para essa nova API.

Por exemplo, os frameworks e arquiteturas de API mais comuns incluem REST, GraphQL e gRPC; cada um tem seus próprios pontos fortes e fracos.

• REST: simples, intuitivo e onipresente, mas não é ideal para consultas complexas e não oferece digitação robusta.
  
  
• GraphQL: eficiente, com digitação robusta e documentação integrada. Mas o GraphQL também pode ser complexo e exigir mais configuração e conhecimentos específicos do que o REST.
  
  
• gRPC: rápido, com digitação forte, geração automática de código e streaming bidirecional. O gRPC é frequentemente usado para comunicação de microsserviços. Mas, como um framework mais novo, pode haver uma curva de aprendizado, e seu formato de documentação é binário em vez de legível por humanos.

Ao projetar a API, a equipe também decidirá qual tipo de autenticação é apropriado (como o OAuth 2.0) e se a API deve estar atrás de um API Gateway.

Um documento de especificação descreve a estrutura, o comportamento e a funcionalidade de uma API de forma padronizada. Ele fornece uma fonte única da verdade com informações sobre como a API é criada, o que ela pode fazer e como interagir com ela.

A especificação padronizada mais popular é a OpenAPI, que permite aos desenvolvedores definir caminhos, métodos, parâmetros, métodos de autenticação e muito mais. A OpenAPI é usada especificamente para APIs REST e é compatível com um conjunto de ferramentas de código aberto chamado Swagger, que oferece geração de código, edição e criação automática de documentação.

Para o GraphQL, a especificação equivalente é o esquema do GraphQL, um contrato fortemente redigido escrito em linguagem de definição de esquema, ou SDL, um formato legível por humanos. O ecossistema GraphQL oferece algumas ferramentas diferentes que aproveitam esse esquema de maneiras que oferecem funcionalidades semelhantes à OpenAPI; por exemplo, GraphiQL é um ecossistema de desenvolvimento integrado (IDE) no navegador para os desenvolvedores usarem como uma área de testes.

Para o gRPC, os buffers de protocolo, ou protobuf, são um formato de serialização e linguagem de definição de interface (IDL) que serve como o formato de arquivo mais usado para especificações. O Protobuf não oferece testes interativos, embora existam IUs da web que permitem isso.

Nesta etapa, os desenvolvedores começam a programação, seguindo o plano de projeto da API definido na etapa anterior. Um sistema de controle de versão é usado para rastrear as versões e alterações de código durante todo o processo de desenvolvimento.

O padrão do setor para sistemas de controle de versão é o Git, um software de código aberto que rastreia as alterações no código armazenadas localmente no dispositivo de um desenvolvedor. Os desenvolvedores usam o Git para criar, gerenciar e rastrear alterações em seu código, mas precisam de um local para que o código seja acessível para eles mesmos e para os outros.

O GitHub é o serviço de hospedagem do Git mais popular, oferecendo níveis gratuitos e pagos, que permitem o armazenamento, a recuperação e a colaboração em repositórios de código do Git. Existem alternativas para hospedar repositórios Git, incluindo GitLab, AWS CodeCommit e Microsoft Azure Repos.

Os testes de API são realizados durante e após a fase de desenvolvimento da API; os testes contínuos ajudam no desenvolvimento, revelando as vulnerabilidades e necessidades e permitindo atualizações regulares.

O teste de unidade envolve isolar pequenas partes do código e testá-las individualmente. No exemplo da API de uma empresa de software, digamos que a equipe precise testar a resposta a uma solicitação para recuperar as informações de um usuário. O comando GET tem como objetivo recuperar o nome e o endereço de e-mail de um usuário a partir do número de ID desse usuário em um banco de dados de clientes. Os testes de unidade envolveriam garantir que esta solicitação GET recupere as informações pretendidas e que uma solicitação para um ID de usuário inexistente retorne uma mensagem de erro apropriada.

Os testes de integração geralmente são executados após os testes de unidade e são usados para detectar problemas que os testes de unidade não detectam. Os testes de integração ajudam a garantir que vários componentes ou serviços possam se comunicar conforme o esperado por meio da API.

Voltando ao nosso exemplo, digamos que uma funcionalidade da API seja o envio de um webhook, ou notificação, de um sistema para outro no caso de um determinado evento, como a adição de um novo cliente. Para garantir que isso funcione, é configurado um teste de integração com um servidor falso que recebe uma notificação e toma a ação esperada quando as informações de um novo cliente são adicionadas ao CRM.Esse processo é repetido para todas as integrações.

O teste de contrato de API garante que uma API faça o que os usuários esperam que ela faça. O contrato é normalmente estruturado como um arquivo de especificação da OpenAPI, que é um documento padrão legível por máquina que apresenta os elementos da funcionalidade e dos recursos de uma API. Um arquivo de especificação de API é normalmente escrito em JSON ou YAML e inclui elementos como endpoints da API, métodos de autenticação, formatos específicos de solicitações e respostas aceitáveis, metadados e parâmetros de entrada.

Avaliar o desempenho da API geralmente envolve avaliar sua velocidade e eficiência. Nessa etapa, os testadores procuram medir o tempo de resposta das consultas, as taxas de erro, o uso de recursos (como CPU e uso de memória), a latência e a taxa de transferência. Compreender o desempenho de uma API nesse estágio pode ajudar a revelar gargalos ou redundâncias que podem retardar a experiência do usuário.

As APIs são frequentemente usadas para transmitir dados confidenciais, tornando o teste de segurança um componente vital. Os testes de segurança de API basicamente tentam comprometer a API de várias maneiras para garantir sua segurança e estabilidade. Essas tentativas podem incluir testes de validação de entrada para garantir que os dados só sejam aceitos quando inseridos em formatos pré-aprovados.

Os testes de validação de entrada procuram por vários tipos de ataques. Entre os tipos mais comuns de ataques estão a injeção de SQL, em que agentes mal-intencionados inserem códigos maliciosos em uma aplicação. O SQL é uma linguagem usada para comunicação com bancos de dados, e determinados comandos SQL universais podem acionar respostas não autorizadas, como uma lista de todos os usuários.

Outros métodos de testes de segurança incluem o teste de autenticação, que garante que as medidas de segurança de identificação, como a biometria, funcionem corretamente, e o teste de autorização, que garante que os usuários possam acessar apenas as funcionalidades para as quais foram aprovados.

Os testes de segurança são realizados durante e após a fase de desenvolvimento, e novas funcionalidades de inteligência artificial (IA) e automação estão melhorando a intensidade e a precisão desses testes. As ferramentas de testes de segurança de IA podem gerar testes automaticamente, verificar o código em busca de erros, analisar dados de desempenho para ajudar a prever problemas e sinalizar comportamentos anômalos e muito mais.

Em setores como o de saúde e serviços financeiros, existem regulamentos, leis e diretrizes para proteger a segurança e a privacidade dos usuários. Exemplos incluem HIPAA (informações de saúde dos EUA), RGPD (informações pessoais da União Europeia) e CCPA (informações pessoais da Califórnia).

O teste de conformidade é um teste que garante que a API esteja em conformidade com quaisquer leis e diretrizes aplicáveis. Por exemplo, o RGPD concede o "direito de ser esquecido", o que significa que os usuários podem solicitar a exclusão completa dos seus dados sem demora injustificada. O teste de conformidade para uma API em conformidade com o RGPD exigiria a garantia de que essa regra seja seguida.

O estágio de implementação é o lançamento da API. Ela foi testada quanto à funcionalidade, segurança e conformidade, e está pronta para ser usada. No estágio de implementação, a API migra do ambiente de testes para o ambiente de produção ao vivo. Há várias etapas envolvidas na implementação de APIs.

Antes da implementação, a equipe deve realizar outra avaliação para garantir que a infraestrutura de suporte, a documentação da API, o suporte ao usuário, as estratégias de distribuição e comunicação e os protocolos de monitoramento estejam concluídos e prontos para uso. Essa lista de verificação pode incluir a escalabilidade de servidores, a configuração de alertas e notificações, a criação de uma página de perguntas frequentes, o envio de um anúncio aos clientes (ou um anúncio público) e muito mais.

CI/CD, que significa integração contínua/implementação contínua, é um conjunto de práticas que automatizam e simplificam os ciclos de desenvolvimento, teste e entrega de software. É uma prática fundamental dentro da metodologia de DevOps. Assim como as aplicações de software, as APIs também são comumente incorporadas nos pipelines de CI/CD para agilizar e automatizar a implementação, o teste e a atualização de APIs.

Um API gateway é uma camada de software que fornece um único ponto de entrada para os clientes acessarem uma variedade de serviços de back-end ou várias instâncias de um serviço de back-end. Os API Gateways podem oferecer diversas vantagens:

• Simplicidade: os clientes só precisam manter o controle de um único URL de serviço em vez de muitos
  
  
• Balanceamento de carga: uma organização pode distribuir o tráfego de um único serviço em várias instâncias para distribuir a carga e evitar gargalos de desempenho
  
  
• Segurança e governança: um gateway pode ser usado para aplicar protocolos de segurança e governança padronizados em muitas APIs. 
  
  
• Cache: um gateway pode ajudar com o cache ao armazenar dados acessados com frequência em vários serviços. Isso ajuda a acelerar as respostas e melhorar o desempenho.

As organizações geralmente emitem versões beta para usuários selecionados a fim de testar uma API antes de liberá-la totalmente para o público. Isso permite que a organização encontre e corrija bugs, solicite feedback, meça o desempenho e promova a API em um ambiente mais seguro e controlado.

Após a conclusão da lista de verificação e de todos os lançamentos beta, é hora de "executar o interruptor" e implementar completamente a API. Esse processo pode incluir o início de estratégias de distribuição para informar ainda mais os clientes internos ou externos sobre a API e incentivar seu uso. O processo de distribuição também pode incluir a publicação de guias do usuário e outros contatos públicos, atualizar um site ou diretório de APIs e ajustar as configurações para permitir o acesso instantâneo em vez de exigir autenticação privada.

Um dos principais benefícios de entender e planejar um ciclo de vida completo da API é garantir que o monitoramento, a observabilidade e a manutenção sejam priorizados desde o início. O trabalho não está concluído no lançamento; ainda há trabalho a ser feito.O monitoramento de API é um processo contínuo, projetado para observar o desempenho de uma API no mundo real, em tempo real.

As principais métricas para monitoramento incluem o tempo de resposta, ou quanto tempo leva para a API responder às solicitações; taxa de erro ou a porcentagem de solicitações que falham; rendimento e tráfego, ou o número de solicitações que a API pode processar; e a análise de infraestrutura, que mede a carga e a integridade dos servidores.

O elemento de manutenção vem na resposta aos dados coletados pelas ferramentas de monitoramento. A manutenção pode vir na forma de correção de bugs, otimização de desempenho ou até mesmo adição de novos recursos ou funcionalidades.

No nosso exemplo de CRM, as ferramentas de monitoramento podem detectar que a latência é alta quando os dados do cliente são enviados de uma plataforma para outra; a fase de manutenção pode lidar com isso reduzindo redundâncias de código, ajustando as configurações de cache ou realocando servidores para ficarem mais próximos dos clientes que eles atendem.

O fim do ciclo de vida de uma API é tão importante, dinâmico e informativo quanto qualquer outra etapa.

O controle de versão é o processo estendido de manter a eficácia de uma API por meio de atualizações ao longo de sua vida útil ativa. O segredo do controle de versão é oferecer alterações e melhorias sem comprometer a funcionalidade existente para os usuários já estabelecidos.

Para correções de bugs simples e afins, as atualizações normalmente são lançadas sem a aplicação de uma nova versão da API, já que essas pequenas alterações são consideradas "não disruptivas". Mas, para mudanças "disruptivas", nas quais uma nova versão não é compatível com a versão que pretende substituir, é uma boa prática introduzir a mudança como uma nova versão.

A comunicação, tanto inicial quanto frequente, é fundamental para o controle de versão. Uma prática comum é oferecer suporte a versões paralelas: a versão mais antiga permanece ativa e funcional junto com a nova versão, e os desenvolvedores comunicam as alterações para incentivar os usuários a migrar para a nova versão. Depois que todos os usuários ou uma quantidade suficiente tiverem migrado, a versão antiga poderá ser desativada.

A descontinuação é a remoção permanente e a desativação de uma API. Nem todas as APIs são descontinuadas, mas é comum que uma API seja substituída eventualmente. Existem vários motivos pelos quais uma API pode ser descontinuada:

• Uma nova versão oferece desempenho melhor
• As necessidades de conformidade ou segurança não são mais atendidas adequadamente
• Mudanças comerciais ou financeiras dentro da organização
• Incompatibilidade com softwares mais recentes

Após a descontinuação, uma API não será mais funcional. Mas existem algumas etapas que podem ajudar a facilitar essa transição.

A descontinuação de uma API requer discussão. É necessário desativar a API e por quê? Qual será a alternativa, se houver? Quem precisará ser informado sobre a descontinuação iminente?

Normalmente, a organização anunciará que uma API está prestes a ser descontinuada. Este anúncio inclui todas as informações necessárias para os usuários da API, como por que essa mudança está acontecendo, quando ela acontecerá e quais ações o usuário precisa tomar, se houver.

Em seguida, a API é oficialmente descontinuada. A API nesse momento permanece operacional, mas não receberá novas atualizações ou funcionalidades. O período de descontinuação foi projetado para dar ao usuário tempo e consciência para fazer os ajustes necessários.

O "dia do pôr do sol" é quando a API pública é totalmente desativada, momento em que as solicitações não serão mais respondidas e os clientes que tentarem acessar a API receberão uma mensagem de erro. É uma boa prática atualizar a documentação para refletir essa mudança e liberar qualquer espaço no servidor ou outra infraestrutura que a API estivesse usando.

Uma análise após a descontinuação de uma API pode ser um exercício útil. As equipes podem discutir as lições aprendidas durante todo o ciclo de vida da API e como elas podem ser aplicadas em projetos futuros.