Ciclo de vida do desenvolvimento da API

Você está visualizando a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Toda organização tem um ciclo de vida de desenvolvimento de software (SDLC, na sigla em inglês) exclusivo. Muitas vezes, é necessário sincronizar e alinhar a implantação do proxy de API com os mesmos processos que você usa atualmente para desenvolver, testar e implantar outros aplicativos.

Os Serviços de API oferecem ferramentas e APIs RESTful que permitem integrar a implantação e o gerenciamento de proxy de API no SDLC da organização. Um uso comum da API RESTful é escrever scripts ou códigos que implantam proxies de API de maneira programática ou que migram proxies de API de um ambiente para outro, como parte de um processo automatizado maior que também implanta ou migra outros aplicativos. Os Serviços de API não fazem suposições sobre seu SDLC (ou qualquer outra pessoa, para isso). Em vez disso, ele expõe funções atômicas que podem ser coordenadas pela equipe de desenvolvimento para automatizar e otimizar o ciclo de vida de desenvolvimento da API.

As APIs de serviços da API são documentadas na Referência da API. Consulte Primeiros passos com a API.

Ambientes

Toda organização no Apigee Edge tem pelo menos dois ambientes de implantação disponíveis para proxies de API: "teste" e "prod". A distinção entre os dois ambientes é arbitrária. Cada ambiente é simplesmente identificado por um conjunto diferente de endereços de rede (URLs). O objetivo é fornecer um domínio no qual você possa criar e verificar proxies de API antes que a API seja exposta para desenvolvedores externos.

Você pode aproveitar esses ambientes para sincronizar o desenvolvimento de proxy de API processado com seu SDLC. Cada ambiente é definido por um endereço de rede, permitindo separar o tráfego entre os proxies de API em que você está trabalhando e aqueles que são acessados por aplicativos no tempo de execução. Os endereços de rede disponíveis para cada ambiente são definidos no conjunto de VirtualHosts disponíveis nele.

A entrada, o TLS/SSL do servidor é ativado automaticamente para cada ambiente. Dois VirtualHosts são predefinidos em cada ambiente: default e secure. O padrão define um endereço HTTP, enquanto segurança define um endereço HTTP/S, com TLS/SSL pré-configurado no servidor. Em uma configuração de proxy de API, você indica em quais hosts de host o ProxyEndpoint deve ouvir. Ao promover para produção, você normalmente desativa o HTTP removendo o default VirtualHost da configuração de proxy da API.

Por exemplo, o seguinte ProxyEndpoint detecta em HTTP e HTTPS.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>default</VirtualHost>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

Ao excluir o VirtualHost default da configuração do ProxyEndpoint, você cria um proxy de API que detecta apenas HTTPS e não em HTTP.

<HTTPProxyConnection>
  <BasePath>/v0/weather</BasePath>
  <Properties/>
  <VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>

É possível ver quais VirtualHosts estão disponíveis em um ambiente, selecionando Ambientes no menu principal da IU de gerenciamento.

Ambientes também fornecem segregação de dados e recursos. Por exemplo, é possível configurar diferentes caches em teste e prod, que podem ser acessados apenas por proxies de API em execução nesse ambiente. Além disso, as chaves de API emitidas no ambiente de teste não são válidas no ambiente de produção e vice-versa.

Como implantar proxies de API em ambientes

Ao criar um proxy de API, você precisará decidir em qual ambiente trabalhará. É possível criar um novo proxy de API na produção, mas isso não é recomendado, pois você pode expor uma API aos desenvolvedores antes que ela esteja pronta. Em geral, comece criando um proxy de API em test que, depois do teste, você promova para prod.

Para mais informações, consulte Noções básicas sobre a implantação.

Desenvolvimento iterativo em teste

À medida que você trabalha em um proxy de API, os serviços de API salvam as iterações da sua configuração como revisão. Ao implantar um proxy de API, você escolhe uma revisão específica para implantar. Normalmente, você implanta a revisão mais recente e, se necessário, reverte para o número de revisão anterior. Você pode escolher onde implantar essas revisões. Por exemplo, você pode promover uma revisão para produção para permitir que os desenvolvedores comecem a trabalhar com sua API. Ao mesmo tempo, é possível iterar várias revisões em teste, em que você adiciona recursos ou ajusta as políticas. Em seguida, quando tudo estiver pronto, será possível implantar a nova revisão para o produto, substituindo a revisão atual nesse ambiente. Com esse método, você pode ter uma revisão em tempo real da API disponível para desenvolvedores durante o desenvolvimento.

Promoção para produção

Quando um proxy de API tiver sido totalmente implementado e testado, ele estará pronto para ser promovido a "prod". A revisão do proxy da API em teste será usada para substituir a revisão do proxy de API implantado em prod.

Os serviços de API fornecem recursos para garantir a implantação perfeita de proxies de API, minimizando o impacto nos aplicativos e usuários finais durante o procedimento de implantação.

Implantação de scripts

A IU de gerenciamento do Apigee Edge permite que você implante proxies de API para produzir diretamente do criador de proxy de API. No entanto, em muitas situações, os requisitos de segurança, confiabilidade e consistência imporão as equipes de desenvolvimento de scripts para os scripts. Para isso, escreva códigos e scripts que invoquem a API RESTful exposta pelos serviços da API.

Recursos ambientais

Para ter mais controle durante a promoção, é recomendável iterar somente em proxies de API em teste e fazer quantas alterações forem necessárias nos proxies de API implantados no prod.

Para fazer isso, você precisa garantir que determinados recursos associados a cada ambiente sejam configurados de maneira que eles possam permanecer estáticos em uma configuração de proxy de API.

• URLs de destino: é comum que proxies de API chamem diferentes URLs de back-end durante testes e produção. Use as configurações do TargetServer para criar configurações de TargetEndpoint independentes do ambiente. Consulte Balanceamento de carga entre servidores de back-end.
• Caches e mapas de chave-valor: os dois recursos de persistência são delimitados por ambiente. É preciso garantir que as convenções de nomenclatura sejam usadas para permitir que os proxies da API armazenem dados sem exigir alterações de configuração durante a promoção. Consulte Como criar e editar um cache de ambiente.
• Destinos de destaque de serviço: as chamadas de serviço podem usar destinos diferentes dependendo do ambiente, se, por exemplo, uma ServiceCalling no ambiente de teste consome um serviço de demonstração. Consulte Política de frase de destaque de serviço.

Para tornar as configurações de proxy da API independentes do ambiente, você também pode usar instruções condicionais. A instrução condicional criada com a variável environment.name pode ser usada para avaliar o ambiente atual antes de aplicar uma política ou antes de rotear para um URL no back-end.

Para mais informações, consulte Noções básicas sobre a implantação.