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.

A 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 estão a ser 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.