Ferramentas para Desenvolvedores

Você está vendo a documentação do Apigee Edge.
Acesse a 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 IU ou fazer solicitações HTTP às APIs para acessar os 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 também só pode ser realizado usando a API.

A tabela a seguir descreve como acessar a IU 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 IU clássica do Edge

Para acessar a interface do Edge para o 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 interface do usuário do Edge, você pode:

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

A imagem a seguir mostra o editor de proxy de API na IU que você pode usar para criar e configurar um proxy de API:

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

Usar a API Edge

É possível usar 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 pela interface.

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

Para uma lista completa das APIs Apigee Edge, consulte a Referência da API 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 organização. Exemplo: https://api.enterprise.apigee.com/v1/organizations/org_name
  • Um endpoint que aponta para o recurso de borda que você está acessando.

Por exemplo, se o nome da organização for apibuilders, todas as chamadas feitas para a API usarão 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 têm escopo por ambiente. Por padrão, dois ambientes são fornecidos: teste e produção. Por exemplo, os caches têm escopo de acordo com o ambiente. Um cache compartilhado chamado "mycache" é incluído por padrão em todos os ambientes.

Você pode 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 o acesso

É necessário autenticar-se no servidor de API ao chamar as APIs. É possível 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 a autenticação de dois fatores para sua conta da Apigee.

Limites da API Edge

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

  • 10.000 chamadas por minuto para organizações com 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 esses limites retornam um código de status 429 Too Many Requests.

Dicas para trabalhar com as APIs do Edge

Nesta seção, descrevemos algumas técnicas que facilitam o trabalho com as APIs Edge.

Como abreviar URLs de solicitação

Ao criar seu URL de solicitação para as APIs Edge, use as seguintes abreviações:

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

Se você usar abreviações, use-as de maneira consistente. Ou seja, abrevie 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 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 amostras de solicitações de API usando curl, um cliente HTTP amplamente utilizado. Se você precisar instalar o curl, faça o download em http://curl.haxx.se.

As chamadas para a API são compatíveis com a compactação gzip nas respostas. Se você definir 'Accept-Encoding: gzip, deflate' nas chamadas de API, qualquer resposta com mais de 1.024 bytes será retornada no formato gzip.

Formatar solicitações e respostas XML e JSON

Por padrão, a API Edge retorna dados no formato JSON. Para muitas solicitações, é possível receber a resposta de volta 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 -

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>

Esse exemplo usa prettyprint para exibir os resultados canalizando a resposta por meio de xmllint.

O utilitário acurl não oferece suporte ao cabeçalho Accept. Como resultado, só é possível receber respostas em formato JSON com acurl.

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

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 usar POST ou PUT em 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

Por padrão, todas as organizações que usam o Apigee Edge têm pelo menos dois ambientes que podem ser usados para desenvolver, testar e implantar APIs: "test" (teste) e "prod". Use o ambiente de "teste" para desenvolver e testar suas APIs antes de disponibilizá-las publicamente. Somente os desenvolvedores internos podem acessar as APIs implantadas no ambiente de teste. Implante as APIs no ambiente "prod" para disponibilizá-las publicamente aos desenvolvedores de apps.

Depuração e testes

A Apigee fornece uma ferramenta de rastreamento que permite depurar fluxos de solicitação e resposta completos. Os resultados do trace exibem cabeçalhos e payloads de solicitação e resposta, execução de políticas, valores de variáveis e qualquer erro que possa ter ocorrido durante o fluxo.

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

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

A figura a seguir mostra os resultados do rastro:

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

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

  • Solicitação original recebida do cliente: mostra o verbo e o caminho do URI da 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 app cliente solicitante depois que o fluxo de resposta é executado.