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:
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:
- OAuth2
- SAML
- Autenticação básica (não recomendada)
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:
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.