Ferramentas para Desenvolvedores

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

Como provedor de serviços, você desenvolve APIs para consumo por apps clientes. Para criar, configurar, e manter proxies e produtos de API, use a interface ou faça solicitações HTTP às 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 e produtos de API. Um subconjunto de tarefas também pode ser realizado usando a 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 Edge, use o seguinte URL:

https://apigee.com/edge

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

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

http://ms-ip:9000

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

Usando a interface do Edge, é possível:

  • Criar proxies de API editando o código e rastreando fluxos de solicitação pelos proxies.
  • Criar produtos de API que agrupam proxies para exposição a solicitações de clientes.
  • Gerenciar desenvolvedores e apps de desenvolvedores.
  • Configurar 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 que pode ser usado para criar e configurar um proxy de API:

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

Usar a API Edge

É possível usar a API Edge para gerenciar seus recursos de API. As APIs também fornecem acesso a recursos de baixo nível que não são expostos pela interface.

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

Para uma lista completa das APIs do Apigee Edge, consulte a referência da API do Apigee Edge.

Entender o caminho base da API Edge

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

  • Um caminho base que inclui o nome da sua organização. Por 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, cada chamada feita para a API vai usar o seguinte caminho base:

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

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

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

Muitos recursos são definidos pelo ambiente. Dois ambientes são fornecidos por padrão: teste e produção. Por exemplo, os caches são definidos pelo ambiente. Um cache compartilhado chamado "mycache" é incluído por padrão em todos os ambientes.

É possível listar 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 o acesso

Você precisa se autenticar no servidor de API ao chamar as APIs. É possível fazer isso de uma das seguintes maneiras:

Além disso, a Apigee recomenda o uso da autenticação de dois fatores, conforme descrito em Ativar a autenticação de dois fatores na sua conta da Apigee.

Limites da API Edge

Cada organização é limitada às seguintes taxas de chamada da API Edge:

  • 10.000 chamadas por minuto para organizações em planos pagos
  • 600 chamadas por minuto para organizações de teste

Os códigos de status HTTP 401 e 403 não são contabilizados nesse limite. Todas as chamadas que excedem estes limites retornam um código de status 429 Too Many Requests.

Dicas para trabalhar com APIs Edge

Esta seção descreve algumas técnicas que facilitam o trabalho com as APIs Edge.

Abreviar URLs de solicitação

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

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

Se você usar abreviações, elas precisam ser consistentes. Ou seja, abreviar todos os elementos no caminho, conforme observado acima e ilustrado no exemplo a seguir, ou nenhum. O uso de elementos completos e abreviados no mesmo caminho resulta em um 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

Use um cliente HTTP para fazer solicitações à API. Muitos exemplos na documentação fornecem solicitações de API de amostra usando curl, um cliente HTTP amplamente usado. Se você precisar instalar curl, faça o download em http://curl.haxx.se.

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

Formatar solicitações e respostas XML e JSON

A API Edge retorna dados como JSON por padrão. Para muitas solicitações, é possível receber a resposta enviada como XML. Para fazer isso, defina o cabeçalho da solicitação Accept como application/xml, conforme mostrado no 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 -

Ela será parecida com o exemplo a seguir:

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

Observação: este exemplo usa prettyprint para mostrar os resultados transmitindo a resposta por xmllint.

O utilitário acurl não oferece suporte ao cabeçalho Accept. Como resultado, só é possível receber respostas formatadas em 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, é possível usar xmllint:

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

Ao postar ou colocar payloads em 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 tem, por padrão, pelo menos dois ambientes que podem ser usados para desenvolver, testar e implantar APIs: "teste" e "produção". Use o ambiente de "teste" para desenvolver e testar suas APIs antes de disponibilizá-las publicamente. Somente os desenvolvedores internos podem acessar APIs implantadas no ambiente de teste. Implante suas APIs no ambiente de "produção" para disponibilizá-las publicamente aos desenvolvedores de apps.

Depuração e testes

A Apigee oferece uma ferramenta de rastreamento que permite depurar fluxos de solicitação e resposta de ponta a ponta. Os resultados do rastreamento mostram 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.

Principais pontos de dados para uso na solução de problemas:

  • Marcações de tempo: use marcações de tempo para ver quanto tempo cada etapa leva para ser executada. A comparação das marcações de tempo ajuda a isolar as políticas que estão demorando mais para serem executadas e atrasando as chamadas de API.
  • Caminho base: ao verificar o caminho base, é possível garantir que uma política esteja encaminhando a mensagem para o servidor correto.
  • Resultados da execução da política: esses resultados permitem verificar se a mensagem está sendo alterada conforme o esperado, por exemplo, se a mensagem está sendo transformada de XML para JSON ou se está sendo armazenada em cache.

A figura a seguir mostra os resultados do rastreamento:

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

Cada sessão de rastreamento é dividida nas seguintes etapas principais:

  • Solicitação original recebida do cliente: mostra 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: mostra a mensagem de solicitação enviada a o serviço de back-end pelo proxy de API.
  • Resposta retornada pelo serviço de back-end: mostra os cabeçalhos de resposta e o payload retornados pelo serviço de back-end.
  • Resposta final enviada ao cliente: a mensagem de resposta retornada ao app cliente solicitante depois que o fluxo de resposta é executado.