Estás viendo la documentación de Apigee Edge.
Ir a la
documentación de Apigee X. info
Como proveedor de servicios, desarrollas APIs para que las consuman las apps cliente. Para crear, configurar, y mantener proxies de API y productos de API, puedes usar la IU o realizar solicitudes HTTP a las APIs para acceder a servicios RESTful, como se describe en las siguientes secciones.
Usa la IU de Edge
La IU de Apigee Edge es una herramienta basada en el navegador que puedes usar para crear, configurar y administrar proxies de API y productos de API. También se puede realizar un subconjunto de tareas solo con la API, también.
En la siguiente tabla, se describe cómo acceder a la IU de Edge:
| Producto | Nombre de la IU | URL de acceso |
|---|---|---|
| Edge | IU de Edge | Para acceder a la IU de Edge, usa la siguiente URL: https://apigee.com/edge Para obtener un instructivo sobre el uso de la IU de Edge, consulta Compila tu primer proxy de API. |
| Edge para la nube privada | IU clásica de Edge | Para acceder a la IU de Edge para Edge para la nube privada, usa la siguiente URL: http://ms-ip:9000 Donde ms-ip es la dirección IP o el nombre de DNS del nodo del servidor de administración. |
Con la IU de Edge, puedes hacer lo siguiente:
- Crear proxies de API mediante la edición de código y el seguimiento de los flujos de solicitudes a través de tus proxies
- Crear productos de API que agrupen proxies para la exposición a solicitudes de clientes
- Administrar desarrolladores y apps para desarrolladores
- Configurar tus entornos de prueba y producción
- Implementar aplicaciones de JavaScript y Node.js
En la siguiente imagen, se muestra el editor de proxies de API en la IU que puedes usar para crear y configurar un proxy de API:

Usa la API de Edge
Puedes usar la API de Edge para administrar tus recursos de API. Las APIs también proporcionan acceso a capacidades de bajo nivel que no expone la IU.
Los extremos de la API suelen tomar datos que contienen información de configuración y requieren que tú
pases información de autenticación, como el nombre de usuario y la contraseña, para acceder a ellos. Siguiendo los principios de RESTful
, puedes llamar a los métodos HTTP GET, POST, PUT y
DELETE en cualquiera de los recursos de la API.
Para obtener una lista completa de las APIs de Apigee Edge, consulta la referencia de la API de Apigee Edge.
Información sobre la ruta base de la API de Edge
La ruta que usarás en las solicitudes a la API concatena lo siguiente:
- Una ruta base que incluye el nombre de tu organización Por ejemplo:
https://api.enterprise.apigee.com/v1/organizations/org_name - Un extremo que apunta al recurso de Edge al que accedes
Por ejemplo, si el nombre de tu organización es apibuilders, cada llamada que realices a la
API usará la siguiente ruta base:
https://api.enterprise.apigee.com/v1/organizations/apibuilders
Para recuperar una lista de proxies de API en tu organización, llamarías a GET en:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
Muchos recursos están dentro del alcance del entorno. De forma predeterminada, se proporcionan dos entornos: prueba y producción. Por ejemplo, las memorias caché están dentro del alcance del entorno. Una caché compartida llamada "mycache" se incluye de forma predeterminada en cada entorno.
Puedes enumerar las memorias caché llamando a GET en el recurso de caché de la siguiente manera:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches
Autentica el acceso
Debes autenticarte en el servidor de la API cuando llames a las APIs. Puedes hacerlo de una de las siguientes maneras:
- OAuth2
- SAML
- Autenticación básica (no se recomienda)
Además, Apigee recomienda que uses la autenticación de dos factores, como se describe en Habilita la autenticación de dos factores para tu cuenta de Apigee.
Límites de la API de Edge
Cada organización está limitada a las siguientes frecuencias de llamadas a la API de Edge:
- 10,000 llamadas por minuto para organizaciones en planes pagos
- 600 llamadas por minuto para organizaciones de prueba
Los códigos de estado HTTP 401 y 403 no se incluyen en este límite. Cualquier llamada que exceda estos
límites muestra un código de estado 429 Too Many Requests.
Sugerencias para trabajar con las APIs de Edge
En esta sección, se describen algunas técnicas que facilitan el trabajo con las APIs de Edge.
Abreviar las URLs de solicitud
Cuando compilas la URL de solicitud para las APIs de Edge, puedes usar las siguientes abreviaturas:
/e = /environments/o = /organizations/r = /revisions
Si usas abreviaturas, debes usarlas de manera coherente. Es decir, abrevia todos los elementos de la ruta, como se indicó anteriormente y se ilustra en el siguiente ejemplo, o ninguno. Si usas elementos completos y abreviados en la misma ruta, se producirá un error.
Por ejemplo:
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
Ejecuta comandos de curl
Usa un cliente HTTP para realizar solicitudes a la API. Muchos ejemplos de la documentación
proporcionan solicitudes de API de muestra con curl, un cliente HTTP de uso generalizado. Si necesitas
instalar curl, puedes descargarlo de
http://curl.haxx.se.
Las llamadas a la API admiten la compresión gzip en
respuestas. Si configuras 'Accept-Encoding: gzip, deflate' en tus llamadas a la API, cualquier
respuesta superior a 1024 bytes se mostrará en formato gzip.
Formatea solicitudes y respuestas XML y JSON
De forma predeterminada, la API de Edge muestra datos como JSON. Para muchas solicitudes, puedes hacer que la respuesta
se envíe como XML. Para ello, configura el encabezado de la solicitud Accept en
application/xml, como se muestra en el siguiente ejemplo:
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 -
La respuesta debería ser como la siguiente:
<List> <Item>SOAP-Message-Validation-1</Item> <Item>Spike-Arrest-1</Item> <Item>XML-to-JSON-1</Item> </List>
Ten en cuenta que este ejemplo usa prettyprint para mostrar los resultados mediante la canalización de la respuesta a través de
xmllint.
La utilidad acurl no admite el encabezado Accept. Como resultado, solo puedes obtener respuestas con formato JSON con acurl.
Para usar prettyprint en una respuesta JSON, puedes usar la biblioteca de 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
A continuación, se proporciona un ejemplo de la respuesta.
[ "SOAP-Message-Validation-1", "Spike-Arrest-1", "XML-to-JSON-1" ]
Para XML, puedes usar xmllint:
curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -
Cuando publiques o coloques cargas útiles en XML, usa el encabezado 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
Entornos de implementación
De forma predeterminada, cada organización que usa Apigee Edge tiene al menos dos entornos que puede usar para desarrollar, probar e implementar APIs: "prueba" y "producción". Usa el entorno de "prueba" para desarrollar y probar tus APIs antes de que estén disponibles para el público. Solo tus desarrolladores internos pueden acceder a las APIs implementadas en el entorno de prueba. Implementa tus APIs en el entorno de "producción" para que estén disponibles para el público para los desarrolladores de apps.
Depuración y pruebas
Apigee proporciona una herramienta de seguimiento que te permite depurar flujos de solicitud y respuesta de extremo a extremo. Los resultados del seguimiento muestran encabezados y cargas útiles de solicitud y respuesta, ejecución de políticas, valores de variables y cualquier error que pueda haber ocurrido durante el flujo.
Puntos de datos clave para usar en la solución de problemas:
- Marcas de tiempo: Usa marcas de tiempo para ver cuánto tarda en ejecutarse cada paso. La comparación de las marcas de tiempo te ayuda a aislar las políticas que tardan más en ejecutarse que ralentizan las llamadas a la API.
- Ruta base: Verifica la ruta base para asegurarte de que una política enrute el mensaje al servidor correcto.
- Resultados de la ejecución de políticas: Estos resultados te permiten ver si el mensaje se modifica según lo previsto, por ejemplo, si se transforma de XML a JSON o si se almacena en caché.
En la siguiente figura, se muestran los resultados del seguimiento:

Cada sesión de seguimiento se divide en los siguientes pasos principales:
- Solicitud original recibida del cliente: Muestra el verbo y la ruta de URI de la solicitud de la app cliente, los encabezados, los datos del cuerpo y los parámetros de consulta.
- Solicitud enviada a tu servicio de backend: Muestra el mensaje de solicitud que el proxy de API envió a el servicio de backend.
- Respuesta que muestra el servicio de backend: Muestra los encabezados de la respuesta y la carga útil que muestra el servicio de backend.
- Respuesta final enviada al cliente: El mensaje de respuesta que se muestra a la app cliente solicitante una vez que se ejecuta el flujo de respuesta.