Introducción

Estás consultando la documentación de Apigee Edge.
Consulta 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

Cuando registras una app de desarrollador en tu organización, esta debe estar asociada con al menos un producto de API. Como resultado de la vinculación de una app con uno o más productos de API, Edge le asigna una clave de consumidor única a la app.

La clave de consumidor o el token de acceso actúan como credenciales de solicitud. El desarrollador de apps incorpora la clave de consumidor en la app para que, cuando la app envíe una solicitud a una API alojada por Edge, la app pase 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. Ya sea que uses la clave de consumidor o los tokens de OAuth como credenciales de solicitud, el proxy de API valida las credenciales de solicitud en tus proxies de API mediante la inclusión de una política VerifyAPIKey o una política de 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 pasadas en la solicitud, Edge realiza los siguientes pasos:

  • Obtiene las credenciales que se pasan con la solicitud. En el caso de la verificación del token OAuth, Edge verifica que el token no haya vencido y, luego, busca la clave de consumidor que se usó para generarlo.
  • 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 claves de consumidor automáticamente, pero los publicadores de la API deben aplicar la verificación de claves en proxies de API mediante el uso de las políticas adecuadas.

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 permisos de OAuth2.

Niveles de acceso

Cuando defines un producto de API, puedes establecer 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 productos de API privados o solo para uso interno en el portal para desarrolladores, como se describe en las siguientes secciones:

  • En los portales para desarrolladores de Drupal 9, puedes configurar el acceso a los productos de API privados o solo para uso interno en tu portal para desarrolladores, como se describe en Configura los permisos de acceso a los productos de API.
  • En el caso de los portales para desarrolladores de Drupal 7, no puedes agregar productos de API privados o solo de API a tu portal de desarrolladores. Si quieres que los productos de API privada o solo para uso interno estén disponibles para los desarrolladores de apps, debes agregarlos manualmente a una app registrada desde la IU o la API de administración perimetral, como se describe en Registra apps y administra claves de API. Una vez agregado, el desarrollador ve el producto de API asociado con la app en tu portal, como se describe en Administra productos de la API en una app. Si el desarrollador de la app inhabilita el acceso a un producto de la API que es interno o privado, el producto de la API se quita de la app y el administrador del portal debe volver a agregarlo de forma manual.