Ciclo de vida do desenvolvimento de APIs

Esta página aplica-se ao Apigee e ao Apigee Hybrid.

Veja a documentação do Apigee Edge.

As secções seguintes resumem o ciclo de vida de desenvolvimento de APIs com o Apigee.

Desenvolver proxies de API

O Apigee suporta as seguintes opções para o desenvolvimento iterativo de proxies de API:

Para mais informações sobre proxies de API, consulte o artigo Compreender as APIs e os proxies de API.

Desenvolvimento na nuvem com o Apigee

Desenvolva os seus proxies de API com as ferramentas de edição e depuração de proxies de API fornecidas com o Apigee. À medida que trabalha num proxy de API, o Apigee guarda as iterações da sua configuração como revisões.

Quando implementa um proxy de API, escolhe uma revisão específica para implementar. Normalmente, implementa a revisão mais recente e, se necessário, reverte para uma revisão anterior. Consulte o artigo Implementar proxies de API.

Para começar a desenvolver os seus proxies de API com o Apigee, consulte o artigo Criar um proxy de API simples.

Desenvolvimento local com o Apigee no VS Code

Use o Apigee no Visual Studio Code (VS Code) para desenvolver os seus proxies de API e validar a funcionalidade através de testes unitários e manuais (por exemplo, envie um pedido e veja os resultados).

Depois de concluir a validação local, implemente as configurações do proxy de API como arquivos nos seus ambientes do Apigee. Consulte o artigo Implementar proxies de API.

Para começar a desenvolver os seus proxies de API localmente através do Apigee no VS Code, consulte o artigo Crie o seu primeiro proxy de API com o Apigee no VS Code.

Implementar proxies de API

Cria ambientes nos quais implementar proxies de API. A distinção entre diferentes ambientes é arbitrária. Cada ambiente é simplesmente identificado por um conjunto diferente de endereços de rede (URLs). O objetivo é fornecer-lhe um domínio no qual possa criar e validar proxies de API antes de a API ser exposta a programadores externos. Para mais informações, consulte o artigo Acerca dos ambientes e dos grupos de ambientes.

Ao implementar as suas APIs em vários ambientes, pode segregar o tráfego entre os proxies de API nos quais está a trabalhar num ambiente de teste e aqueles aos quais as apps externas estão a aceder no tempo de execução num ambiente de produção.

O Apigee suporta os seguintes tipos de implementação num ambiente:

Tipo Descrição
Proxy Desenvolva e teste os proxies de API nos seus ambientes de desenvolvimento do Apigee e, em seguida, implemente-os nos ambientes de teste de integração e de produção do Apigee. Consulte o artigo Implementar um proxy de API.
Arquivar Desenvolva e teste os seus proxies de API programáveis com o Apigee no VS Code.

Adicionar políticas

O Apigee permite-lhe programar o comportamento da API sem escrever código, através de políticas. Uma política é como um módulo que implementa uma função de gestão específica e limitada. As políticas são concebidas para lhe permitir adicionar tipos comuns de capacidades de gestão a uma API de forma fácil e fiável. As políticas oferecem funcionalidades como segurança, limitação de taxa, transformação e capacidades de mediação, o que lhe permite não ter de programar nem manter esta funcionalidade por conta própria. Também pode escrever scripts e código personalizados (como aplicações JavaScript) que expandem a funcionalidade do proxy de API e lhe permitem inovar com base nas capacidades de gestão básicas suportadas pelas políticas do Apigee. Para mais informações sobre as políticas do Apigee, consulte o artigo O que é uma política?

O Apigee fornece políticas prontas a usar para várias funcionalidades, como gestão de tráfego, segurança, mediação e políticas de extensão. Para ver a lista completa de políticas disponíveis no Apigee, consulte o artigo Vista geral da referência de políticas.

Promover para produção

Escolhe onde implementar uma API. Por exemplo, pode promover uma revisão para um ambiente de produção para permitir que os programadores comecem a trabalhar com a sua API. Ao mesmo tempo, pode estar a iterar várias revisões num ambiente de teste ou local, onde está a adicionar funcionalidades ou a ajustar as políticas. Em seguida, quando tiver tudo pronto, pode implementar a nova revisão no ambiente de produção, substituindo a revisão existente nesse ambiente. Com este método, pode ter sempre uma revisão ativa da sua API disponível para os programadores enquanto desenvolve e testa novas funcionalidades.

Implementação de scripts com a API Apigee

O Apigee fornece uma API RESTful que lhe permite integrar a implementação e a gestão de proxies de API no ciclo de vida de desenvolvimento de software (SDLC) da sua organização. Por exemplo, para garantir que os requisitos de segurança, fiabilidade e consistência são cumpridos, uma utilização comum da API Apigee é escrever scripts ou código que implementam proxies de API de forma programática e os promovem de um ambiente para outro, como parte de um processo automatizado maior.

Para mais informações, consulte a API Apigee.

Gerir recursos do ambiente

Os ambientes oferecem segregação de dados e recursos. Por exemplo, pode configurar diferentes caches nos ambientes test e production aos quais só os proxies de API que são executados nesse ambiente podem aceder. Além disso, as chaves de API emitidas num ambiente de teste não são válidas num ambiente de produção e vice-versa.

Para ter um controlo adicional durante a promoção, recomendamos que itere apenas nos proxies de API num ambiente de teste e faça o menor número de alterações possível aos proxies de API implementados num ambiente de produção.

Para tal, tem de garantir que determinados recursos associados a cada ambiente estão configurados de forma a poderem permanecer estáticos numa configuração de proxy de API.

  • Mapas de chaves-valores (KVMs): se o âmbito for o ambiente, deve garantir que são usadas convenções de nomenclatura para permitir que os proxies de API armazenem dados sem exigir alterações de configuração durante a promoção. Para mais informações, consulte Usar mapas de chaves-valores.
  • URLs de destino: é comum que os proxies de API chamem diferentes URLs de back-end durante os testes e a produção. Pode usar configurações TargetServer para criar configurações TargetEndpoint independentes do ambiente. Para mais informações, consulte
  • Alvos ServiceCallout: os pedidos de serviços podem usar alvos diferentes consoante o ambiente, se, por exemplo, um ServiceCallout no ambiente de teste consumir um serviço de demonstração. Consulte a política de texto de chamada de serviços.

Para tornar as configurações de proxy da API independentes do ambiente, também pode usar declarações condicionais. As declarações condicionais criadas com a variável environment.name podem ser usadas para avaliar o ambiente atual antes de aplicar uma política ou antes de encaminhar para um URL no back-end. Para mais informações, consulte o artigo Condições com variáveis de fluxo.