Ferramentas de desenvolvimento

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Como provedor de serviços, você desenvolve APIs para consumo por apps clientes. Para criar, configurar e manter proxies de API e produtos de API, é possível usar a interface ou fazer solicitações HTTP para APIs para acessar serviços RESTful, conforme descrito nas seções a seguir.

Usar a interface do Edge

A interface do Apigee Edge é uma ferramenta baseada em navegador que pode ser usada para criar, configurar e gerenciar Proxies de API e produtos de API. Um subconjunto de tarefas só pode ser realizado com o uso da API, também.

A tabela a seguir descreve como acessar a interface do Edge:

Produto Nome da interface URL de acesso
Edge interface do Edge

Para acessar a interface do usuário do Edge, use este URL:

https://apigee.com/edge

Para acessar um tutorial sobre como usar a interface do Edge, consulte Crie seu primeiro proxy de API.
Edge para nuvem privada IU clássica do Edge

Para acessar a interface do Edge para nuvem privada, use o seguinte URL:

http://ms-ip:9000

Em que ms-ip é o endereço IP ou nome DNS do nó do servidor de gerenciamento.

Com a IU do Edge, é possível:

  • Crie proxies de API editando o código e rastreando os fluxos de solicitações pelos proxies.
  • Crie produtos de API que agrupem proxies para exposição a solicitações de clientes.
  • Gerenciar desenvolvedores e apps de desenvolvedores.
  • Configure os ambientes de teste e produção.
  • Implementar aplicativos JavaScript e Node.js.

A imagem a seguir mostra o editor de proxy de API na interface do usuário que você pode usar para criar e configurar uma Proxy de API:

Mostra a guia "Develop" selecionada no editor de proxy de API na interface do Edge.

Usar a API Edge

Use a API Edge para gerenciar os recursos da API. As APIs também fornecem acesso a recursos de baixo nível que não são expostos pelo de ML pela IU.

Os endpoints de API geralmente recebem dados que contêm informações de configuração e exigem que você transmitir informações de autenticação, como nome de usuário e senha, para acessá-las. Seguindo RESTful principais, é possível chamar HTTP GET, POST, PUT e DELETE em qualquer um dos recursos da API.

Para uma lista completa de APIs da Apigee Edge, consulte a Referência da API Apigee Edge.

Entender a base da API Edge caminho

O caminho que você vai usar nas solicitações da API concatena o seguinte:

  • Um caminho base que inclui o nome da organização. Exemplo: https://api.enterprise.apigee.com/v1/organizations/org_name
  • Um endpoint que aponta para o recurso do Edge que você está acessando.

Por exemplo, se o nome da sua organização for apibuilders, todas as chamadas feitas para a API usará o seguinte caminho base:

https://api.enterprise.apigee.com/v1/organizations/apibuilders

Para recuperar uma lista de proxies de API em sua organização, chame GET em:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis

Muitos recursos têm escopo por ambiente. Dois ambientes são fornecidos por padrão: teste e prod. Por exemplo, o escopo dos caches é definido pelo ambiente. Um cache compartilhado chamado "mycache" está incluído por padrão em todos os ambientes.

É possível listar os caches chamando GET no recurso de cache da seguinte maneira:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches

Autenticar acesso

É necessário autenticar-se no servidor da API ao chamar as APIs. Você pode fazer isso de uma das seguintes maneiras:

Além disso, a Apigee recomenda que você use a autenticação de dois fatores, conforme descrito em Ativar autenticação de dois fatores para sua conta da Apigee.

Limites da API Edge

Cada organização está limitada às seguintes tarifas de chamada da API Edge:

  • 10.000 chamadas por minuto para organizações com planos pagos
  • 600 chamadas por minuto para organizações que fazem testes

Os códigos de status HTTP 401 e 403 não contam para esse limite. Todas as chamadas que excederem esses retornam um código de status 429 Too Many Requests.

Dicas para trabalhar com as APIs do Edge

Esta seção descreve algumas técnicas que tornam o trabalho com as APIs do Edge mais fácil.

Como abreviar URLs de solicitação

Ao criar o URL de solicitação para as APIs do Edge, você pode usar o seguinte: abreviações:

  • /e = /environments
  • /o = /organizations
  • /r = /revisions

O uso de abreviações precisa ser consistente. Ou seja, abrevie todos os elementos na caminho, conforme observado acima e ilustrado no exemplo a seguir, ou nenhum. O uso de elementos completos e abreviados no mesmo caminho vai resultar em erro.

Exemplo:

THIS:
https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments
CAN BE MUCH SHORTER:
https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments

Executar comandos curl

Usar um cliente HTTP para fazer solicitações à API. Muitos exemplos na documentação fornecer exemplos de solicitações de API usando curl, um cliente HTTP amplamente utilizado. Se você precisar instalar curl, você pode fazer o download em http://curl.haxx.se.

As chamadas para a API oferecem suporte à compactação gzip em de resposta. Se você definir 'Accept-Encoding: gzip, deflate' nas chamadas de API, uma resposta maior que 1.024 bytes é retornada no formato gzip.

Como formatar solicitações e respostas XML e JSON

Por padrão, a API Edge retorna dados como JSON. Para muitas solicitações, você pode receber a resposta enviada como XML. Para fazer isso, defina o cabeçalho da solicitação Accept como application/xml, como mostra o exemplo a seguir:

curl -H "Authorization: Bearer `get_token`" \
  -H "Accept: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  | xmllint --format -

A resposta será semelhante a esta:

<List>
  <Item>SOAP-Message-Validation-1</Item>
  <Item>Spike-Arrest-1</Item>
  <Item>XML-to-JSON-1</Item>
</List>

Observe que este exemplo usa prettyprint para exibir os resultados encadeando a resposta xmllint.

O utilitário acurl não é compatível com o cabeçalho Accept. Como resultado, você pode receba apenas respostas no formato JSON com acurl.

Para usar prettyprint em uma resposta JSON, use a biblioteca Python json.tool:

curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  -H "Accept: application/json" \
  -H "Authorization: Bearer `get_token`" \
  | python -m json.tool

Veja a seguir um exemplo de resposta:

[
  "SOAP-Message-Validation-1",
  "Spike-Arrest-1",
  "XML-to-JSON-1"
]

Para XML, use xmllint:

curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -

Ao fazer POST ou PUT payloads no XML, use o cabeçalho HTTP Content-type:

acurl -H "Content-type:text/xml" -X POST -d \
'<XMLPayload>
 </XMLPayload> ' \
https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address

Ambientes de implantação

Toda organização que usa o Apigee Edge por padrão tem pelo menos dois ambientes que podem ser usados para desenvolver, testar e implantar APIs: "test" e "prod". Use a opção de "teste" para desenvolver e testar suas APIs antes de disponibilizá-las publicamente. Apenas seus desenvolvedores internos podem acessar as APIs implantados no ambiente de teste. Implante as APIs no "prod" de nuvem para torná-las públicas disponíveis para desenvolvedores de apps.

Depuração e testes

A Apigee oferece uma ferramenta de trace que permite depurar e solicitação e resposta completas flui. Os resultados do trace exibem cabeçalhos e payloads de solicitação e resposta, execução de políticas, valores de variáveis e erros que possam ter ocorrido durante o fluxo.

Pontos de dados importantes para usar na solução de problemas:

  • Carimbos de data/hora: use essas marcações para ver quanto tempo leva para cada etapa ser executada. A comparação de carimbos de data/hora ajuda a isolar as políticas que estão demorando mais para serem executadas atrasam as chamadas de API.
  • Caminho base: ao verificar o caminho base, você garante que uma política seja encaminhando a mensagem para o servidor correto.
  • Resultados da execução da política: esses resultados permitem ver se a mensagem foi sendo alteradas conforme o esperado, por exemplo, se a mensagem estiver sendo transformada de XML para JSON ou se a mensagem está sendo armazenada em cache.

A figura abaixo mostra os resultados do trace:

Mostra a guia &quot;Trace&quot; selecionada no editor de proxy de API na interface do Edge.

Cada sessão do Trace é dividida nas seguintes etapas principais:

  • Solicitação original recebida do cliente: exibe o verbo e o caminho do URI de. a solicitação do app cliente, cabeçalhos, dados do corpo e parâmetros de consulta.
  • Solicitação enviada ao serviço de back-end: exibe a mensagem de solicitação enviada ao serviço de back-end pelo proxy de API.
  • Resposta retornada pelo serviço de back-end: exibe os cabeçalhos de resposta. e o payload retornado pelo serviço de back-end.
  • Resposta final enviada ao cliente: a mensagem de resposta retornada ao aplicativo cliente solicitante assim que o fluxo de resposta for executado.