Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
En las siguientes secciones, se presentan los productos de API y los conceptos clave relacionados.
¿Qué es un producto de API?
Como proveedor de API, debes crear productos de API a fin de agrupar tus API y hacer que estén disponibles para los desarrolladores de apps. Puede considerar los productos de API como tu línea de productos.
En particular, un producto de la API agrupa lo siguiente:
- Colección de recursos de API (URI)
- Plan de servicio
- Metadatos específicos de tu empresa para la supervisión o estadísticas (opcional)
Los recursos de API agrupados en un producto de la API pueden provenir de una o más API para que puedas combinar y hacer coincidir recursos a fin de crear conjuntos de atributos especializados, como se muestra en la siguiente figura.
Puedes crear varios productos de API para abordar casos de uso que resuelvan necesidades específicas. Por ejemplo, puedes crear un producto de la API que agrupe varios recursos de asignación para permitir que los desarrolladores integren mapas a sus aplicaciones con facilidad. Además, puedes establecer diferentes propiedades en cada producto de API, como diferentes niveles de precios. Por ejemplo, puedes ofrecer las siguientes combinaciones de productos de la API:
- Un producto de la API que ofrezca un límite de acceso bajo, como 1,000 solicitudes por día, por un precio de oferta. Un segundo producto de la API que otorgue acceso a los mismos recursos, pero con un límite de acceso y un precio más alto.
- Un producto de la API gratuito que ofrece acceso de solo lectura a los recursos. Un segundo producto de la API que proporciona acceso de lectura/escritura a los mismos recursos por un cobro menor.
Además, puedes controlar el acceso a los recursos de API en un producto de API. Por ejemplo, puedes agrupar recursos a los que solo pueden acceder los desarrolladores internos o los clientes que pagan.
Los productos de API son el mecanismo central de autorización y control de acceso a tus API. En Apigee, se aprovisionan las claves de API, no para las API, sino para los productos de las API. En otras palabras, las claves de API se aprovisionan para paquetes de recursos con un plan de servicio adjunto.
Los desarrolladores de apps acceden a los productos de API mediante el registro de sus apps, como se describe en el Registra apps. Cuando una aplicación intenta acceder a un producto de API, Apigee aplica la autorización en el entorno de ejecución para garantizar lo siguiente:
- La aplicación solicitante puede acceder a un recurso de API específico.
- La aplicación solicitante no superó la cuota permitida.
- Si se definen, los alcances de OAuth definidos en el producto de API coinciden con los asociados al token de acceso que presenta la app.
Comprende los conceptos clave
Revisa los siguientes conceptos clave antes de crear tus productos de API.
- Claves de API
- Aprobación automática de claves frente a la manual
- Cuotas
- Alcances de OAuth
- Niveles de acceso
Claves de API
Cuando registras una app de desarrollador en tu organización, esta debe estar asociada con al menos un producto de API. Cuando vinculas una app con uno o más productos de API, Edge le asigna a la app una clave de consumidor única.
La clave de consumidor o el token de acceso actúan como credenciales de solicitud. El desarrollador de la app incorpora la clave de consumidor en la app, de modo que cuando esta realice una solicitud a una API alojada en Edge, la app pasa la clave de consumidor en la solicitud de una de las siguientes maneras:
- Cuando la API usa la verificación de claves de API, la app debe pasar la clave de consumidor directamente.
- Cuando la API usa la verificación de token de OAuth, la app debe pasar un token derivado de la clave de consumidor.
La clave de seguridad de API no se realiza automáticamente. Si se usa la clave de consumidor o los tokens de OAuth como credenciales de solicitud, el proxy de API valida las credenciales de solicitud en tu proxies de API incluyendo una política VerifyAPIKey o una política OAuth/VerifyAccessToken, en el flujo adecuado. Si no incluyes una política de aplicación de credenciales en el proxy de API, cualquier emisor puede invocar tus API. Para obtener más información, consulta Política VerifyAPIKey.
Para verificar las credenciales que se pasaron en la solicitud, Edge realiza los siguientes pasos:
- Obtiene las credenciales que se pasan con la solicitud. En el caso de OAuth la verificación de tokens, Edge comprueba que el token no haya vencido y, luego, busca al consumidor que se usó para generar el token.
- Recupera la lista de productos de API a los que se asoció la clave de consumidor.
- Confirma que el proxy de API actual se incluya en el producto de API, y si la ruta de recursos actual (ruta de URL) está habilitada en el producto de API.
- Verifica que la clave de consumidor no haya vencido o revocado, comprueba que la app no esté revocada y verifica que el desarrollador de apps esté activo.
Si pasan todas las verificaciones anteriores, la verificación de credenciales se realiza correctamente.
En pocas palabras, Edge genera automáticamente claves de consumidor, pero los publicadores de APIs deben aplicar la comprobación de claves en proxies de API usando las políticas apropiadas.
La aprobación automática frente a la manual
De forma predeterminada, todas las solicitudes se aprueban automáticamente a fin de obtener una clave para acceder a un producto de la API desde una app. También puedes configurar el producto de la API para aprobar claves de forma manual. En este caso, deberás aprobar las solicitudes clave de cualquier app que agregue el producto de la API. Para obtener más información, consulta Registra apps y administra claves de API.
Cuotas
Las cuotas pueden proteger tus servidores de backend para un tráfico alto y diferenciar tu línea de productos. Por ejemplo, te recomendamos agrupar recursos con una cuota alta como producto premium y usar el mismo paquete con una cuota más baja como producto básico. Una cuota puede ayudar a proteger tus servidores para que no se sobrecarguen si un producto es popular y recibe una gran cantidad de solicitudes.
Si deseas obtener más información para configurar la cuota, consulta Política de cuotas. Si deseas obtener más información para usar la configuración de cuota de productos en las políticas de cuotas, consulta el siguiente artículo de la comunidad ¿Cómo interactúan los ajustes de cuota en un producto de API con las políticas de cuotas en un proxy de API?.
Alcances de OAuth
Como nivel adicional de seguridad, puedes definir los alcances de OAuth, como una lista separada por comas, que debe estar presente en los tokens de acceso enviados a través del producto. Cuando creas un producto, debes saber todos los alcances que usa tu organización. Los alcances que agregues a un producto deben coincidir con los alcances existentes o el producto no es seguro.
Para obtener más información sobre el uso de permisos con las políticas de OAuth de Edge, consulta Trabaja con alcances de OAuth2.
Niveles de acceso
Cuando defines un producto de API, puedes configurar los siguientes niveles de acceso.
| Nivel de acceso | Descripción |
|---|---|
| Público | Productos de la API que están disponibles para todos los desarrolladores. Puedes agregarlos a los portales para desarrolladores integrados o basados en Drupal. |
| Privado o solo para uso interno | Productos de la API diseñados para uso privado o interno. Nota: No hay diferencia entre los niveles de acceso interno y privado. Selecciona la etiqueta que describa mejor al público objetivo del producto de API. En el portal integrado, puedes agregar productos de la API privados o solo internos, y hacer que estén disponibles para los desarrolladores de apps, según sea necesario. En el caso de los portales para desarrolladores basados en Drupal, puedes administrar el acceso a los productos de API privados o solo para uso interno en tu portal para desarrolladores, como se describe en las siguientes secciones:
|