Estás viendo la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Más información
Como proveedor de servicios, desarrollas APIs para consumo por parte de apps cliente. Para crear, configurar y mantener los proxies y los productos de API, puedes usar la IU o realizar solicitudes HTTP a las APIs para acceder a los 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 y productos de API. Un subconjunto de tareas solo se puede realizar con la API.
En la siguiente tabla, se describe cómo acceder a la IU de Edge:
Producto | Nombre de la IU | URL de acceso |
---|---|---|
Conexión de integración | IU de Edge | Para acceder a la IU de Edge, usa la siguiente URL: https://apigee.com/edge Para ver un instructivo sobre cómo usar la IU de Edge, consulta Compila tu primer proxy de API. |
Edge para la nube privada | IU clásica de Edge | Si quieres acceder a la IU de Edge para Edge de la nube privada, usa la siguiente URL: http://ms-ip:9000 En el ejemplo anterior, 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:
- Para crear proxies de API, edita el código y realiza un seguimiento de los flujos de solicitudes a través de ellos.
- Crea productos de API que agrupen los proxies para exponerlos a las solicitudes de los clientes.
- Administrar desarrolladores y sus apps de desarrolladores
- Configurar los entornos de prueba y producción
- Implementa aplicaciones de JavaScript y Node.js.
En la siguiente imagen, se muestra el editor de proxy 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 la IU no expone.
Los extremos de la API suelen tomar datos que contienen información de configuración y requieren que pases información de autenticación, como el nombre de usuario y la contraseña, para acceder a ellos. Según 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.
Comprende 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 incluya el nombre de la organización Por ejemplo:
https://api.enterprise.apigee.com/v1/organizations/org_name
. - Un extremo que apunta al recurso de Edge al que estás accediendo.
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, debes llamar a GET en:
https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis
Muchos recursos tienen permiso por entorno. De forma predeterminada, se proporcionan dos entornos: prueba y producción. Por ejemplo, el entorno define el alcance de las cachés. De forma predeterminada, se incluye una caché compartida llamada “mycache” en cada entorno.
Para mostrar una lista de las memorias caché, llama 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 llamas a las APIs. Puedes hacerlo de una de las siguientes maneras:
- OAuth2
- SAML
- Autenticación básica (no recomendado)
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 tarifas de llamadas a la API de Edge:
- 10,000 llamadas por minuto para organizaciones con planes pagados
- 600 llamadas por minuto para organizaciones de prueba
Los códigos de estado HTTP 401
y 403
no se descuentan de este límite. Las llamadas que excedan estos límites mostrarán 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.
Abrevia URL de solicitud
Cuando compilas tu URL de solicitud a las APIs de Edge, puedes usar las siguientes abreviaturas:
/e = /environments
/o = /organizations
/r = /revisions
Si usas abreviaturas, debes usarlas de forma coherente. Es decir, abrevia todos los elementos de la ruta, como se indicó más arriba y se ilustra en el siguiente ejemplo, o ninguno. El uso de elementos completos y abreviados en la misma ruta de acceso generará 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 los comandos curl
Usa un cliente HTTP para realizar solicitudes a la API. En muchos ejemplos de la documentación, se proporcionan solicitudes a la API de muestra mediante curl
, un cliente HTTP muy usado. Si necesitas instalar curl
, puedes descargarlo de http://curl.haxx.se.
Las llamadas a la API admiten la compresión gzip en las respuestas. Si configuras 'Accept-Encoding: gzip, deflate'
en tus llamadas a la API, cualquier respuesta que supere los 1,024 bytes se mostrará en formato gzip.
Cómo dar formato a las respuestas y solicitudes XML y JSON
La API de Edge muestra datos en formato JSON de forma predeterminada. Para muchas solicitudes, puedes obtener la respuesta enviada como XML. Para ello, establece 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 verse de la siguiente manera:
<List> <Item>SOAP-Message-Validation-1</Item> <Item>Spike-Arrest-1</Item> <Item>XML-to-JSON-1</Item> </List>
Ten en cuenta que, en este ejemplo, se usa prettyprint
para mostrar los resultados canalizando la respuesta a través de xmllint
.
La utilidad acurl
no admite el encabezado Accept
. Como resultado, solo puedes obtener respuestas en formato JSON con acurl
.
Si deseas usar prettyprint
para una respuesta JSON, puedes usar la biblioteca json.tool
de 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
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 cargas útiles en formato POST o PUT 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, las organizaciones que usan Apigee Edge tienen al menos dos entornos que pueden usar para desarrollar, probar e implementar APIs: “probar” y “prod”. Usa el entorno de "prueba" para desarrollar y probar tus API antes de que estén disponibles para el público. Solo tus desarrolladores internos pueden acceder a las APIs implementadas en el entorno de pruebas. Implementa tus APIs en el entorno “prod” a fin de que estén disponibles públicamente 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 las cargas útiles y los encabezados de solicitud y respuesta, la ejecución de políticas, los valores de las variables y cualquier error que pueda haber ocurrido durante el flujo.
Puntos de datos clave para la solución de problemas:
- Marcas de tiempo: Usa marcas de tiempo para ver cuánto tiempo tarda cada paso en ejecutarse. La comparación de las marcas de tiempo te ayuda a aislar las políticas que tardan más en ejecutarse y que ralentizan las llamadas a la API.
- Ruta base: Cuando verificas la ruta base, puedes asegurarte de que una política enruta el mensaje al servidor correcto.
- Resultados de la ejecución de la política: Estos resultados te permiten ver si el mensaje se altera según lo previsto, por ejemplo, si el mensaje se está transformando de XML a JSON o si el mensaje se está almacenando en caché.
En la siguiente figura, se muestran los resultados de seguimiento:
Cada sesión de Trace se divide en los siguientes pasos principales:
- Solicitud original recibida del cliente: Muestra la ruta del verbo y el URI de la solicitud desde 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 envió el proxy de API al servicio de backend.
- Respuesta que muestra el servicio de backend: Muestra los encabezados de respuesta y la carga útil que muestra el servicio de backend.
- Respuesta final enviada al cliente: Es el mensaje de respuesta que se muestra a la app cliente solicitante una vez que se ha ejecutado el flujo de respuesta.