Introducción
Tanto el CMS como las API de reproducción brindan acceso a sus datos de video de Video Cloud. El propósito de este tema es ayudarlo a comprender la diferencia entre ellos y las mejores prácticas para usarlos.
Diferencias entre CMS y API de reproducción
Las API de reproducción y CMS acceden a los mismos datos de video subyacentes. Sin embargo, existen algunas diferencias clave entre ellos que deberían determinar cuál usa en situaciones particulares.
En general, el CMS API está diseñado para uso de backend, como la integración de Video Cloud con su sistema CMS. La API de reproducción está diseñada para uso frontend para obtener datos de listas de reproducción y videos para reproductores o portales de video (Brightcove Player catalog y playlist Las API utilizan la API de reproducción, por ejemplo).
La siguiente tabla enumera algunas diferencias clave entre las dos API.
| Artículo | API de CMS | API de reproducción |
|---|---|---|
| Tipos de operaciones | crear, leer, actualizar, eliminar | solo lectura: no se pueden modificar datos con la API de reproducción |
| Alcance de las operaciones | Administre todos los aspectos de sus datos de video | Obtenga videos o listas de reproducción específicos, o busque videos |
| Autenticación | Temporal tokens de acceso | Permanente claves de política |
| Actualidad de los datos | Sin almacenamiento en caché, siempre actualizado | Almacenado en caché por hasta 20 minutos |
| Velocidad de respuestas | Más lento | Más rápido (debido al almacenamiento en caché) |
| Acceso | Solo del lado del servidor (COR deshabilitados) | Servidor o del lado del cliente (COR habilitados) |
| Datos | Las solicitudes de videos y listas de reproducción no incluyen URL de fuente de video; se requiere una segunda solicitud para obtener esos | Las solicitudes de videos y listas de reproducción incluyen URL de fuente de video |
Usar URL de medios
Es importante comprender que las URL para representaciones, imágenes y otros activos no son fijas. Brightcove reconfigura el almacenamiento de activos multimedia de vez en cuando y, cuando esto sucede, las URL de activos específicos cambiarán. Si confía en URL codificadas de forma rígida para estos activos en sus páginas o aplicaciones, los enlaces se romperán en algún momento.
Además, todas las URL contienen un TTL token por razones de seguridad del contenido. Esto significa que las URL caducan después de 6 horas de forma predeterminada. La vida útil del token se puede extender hasta 365 días; si desea tokens de mayor duración, Póngase en contacto con el soporte de Brightcove. Tenga en cuenta, sin embargo, que el TTL refleja el tiempo máximo que la CDN almacenará en caché ese activo, pero no garantiza que la URL no cambie antes de que caduque el token.
Para el contenido de VOD, puede especificar un TTL más corto en la URL del manifiesto. Para más detalles, consulte el Manifiesto corto TTL documento.
La mejor manera de evitar que los enlaces a los medios se rompan es recuperarlos de Video Cloud en tiempo de ejecución utilizando el API de CMS o el API de reproducción.
Almacenamiento en caché de URL
Si una solicitud de API en tiempo de ejecución no es una opción, recomendamos obtener las URL de una caché de datos local que se actualice al menos una vez al día, o dentro del tiempo de vida establecido para su TTL tokens, el que sea más corto.
URL estáticas
Brightcove proporciona URL estáticas a archivos de manifiesto de video para activos en su biblioteca de Video Cloud. Esto le brinda la flexibilidad de administrar su contenido en su propio CMS y entregarlo utilizando un esquema de seguridad personalizado.
Esto es importante para los clientes que tienen una arquitectura existente que no permite una llamada a la API de reproducción antes de necesitar las URL de manifiesto. El reproductor también puede utilizar esta función, lo que reduce el tiempo de inicio de la reproducción al eliminar una llamada.
Para más detalles, consulte el Entrega de URL estática documento.
Manifiesto corto TTL
En el flujo de trabajo de reproducción, Brightcove Player llama a la API de reproducción (o API de Edge Auth) para recuperar los manifiestos disponibles para iniciar la reproducción proporcionando una clave de política (o JWT) para la autenticación.
Se ha introducido una capa de almacenamiento en caché para permitir que estas API se escalen y estén altamente disponibles. Esa capa almacena las respuestas de la API de URL del manifiesto firmado y la API de reproducción. Dado que los manifiestos firmados se almacenarán en caché, el TTL debe ser lo suficientemente largo para que sea válido durante el tiempo en caché, además de un búfer para que lo use el jugador.
Los TTL de manifiesto cortos permiten a los espectadores continuar la reproducción sin obstáculos. Además, todas las funciones de entrega dinámica funcionan con TTL de manifiesto corto.
Conflictos de ID de referencia
Esta sección se aplica a la CMS API solo.
Para asegurar la unicidad de los identificadores de referencia, el CMS API bloquea la identificación hasta 3 minutos después de cualquier operación en el video al que está asignado. Esto puede provocar que se devuelvan errores 409 cuando intentas reintentar una solicitud que falla demasiado rápido, o cuando intentas reutilizar una identificación de referencia demasiado pronto después de eliminar el video al que se asignó previamente. Ver el Referencia de mensaje de error para más detalles.