Introduction
Le CMS et les API de lecture donnent accès à vos données vidéo Video Cloud. Le but de cette rubrique est de vous aider à comprendre la différence entre eux et les meilleures pratiques pour les utiliser.
Différences entre le CMS et les API de lecture
Le CMS et les API de lecture accèdent aux mêmes données vidéo sous-jacentes. Cependant, il existe des différences clés entre eux qui devraient déterminer celui que vous utilisez dans des situations particulières.
Généralement, le CMS API est destiné à une utilisation backend, comme l'intégration de Video Cloud à votre système CMS. L'API de lecture est destinée à une utilisation frontale pour récupérer des données de vidéo et de liste de lecture pour les lecteurs ou les portails vidéo (le Brightcove Player catalog et playlist Les API utilisent l'API Playback, par exemple).
Le tableau ci-dessous répertorie quelques différences clés entre les deux API.
| Article | API CMS | API de lecture |
|---|---|---|
| Types d'opérations | créer, lire, mettre à jour, supprimer | lecture seule - aucune donnée ne peut être modifiée à l'aide de l'API de lecture |
| Portée des opérations | Gérez tous les aspects de vos données vidéo | Récupérez des vidéos ou des listes de lecture spécifiques, ou recherchez des vidéos |
| Authentification | Temporaire jetons d'accès | Permanent clés de stratégie |
| Fraîcheur des données | Pas de mise en cache, toujours à jour | Mise en cache jusqu'à 20 minutes |
| Rapidité des réponses | Ralentissez | Plus rapide (à cause de la mise en cache) |
| Accès | Côté serveur uniquement (COR désactivés) | Côté serveur ou client (CORs activés) |
| Données | Les demandes de vidéo et de liste de lecture n'incluent pas les URL de source vidéo ; une deuxième demande est nécessaire pour obtenir ces | Les demandes de vidéo et de playlist incluent les URL de source vidéo |
Utilisation d'URL multimédias
Il est important de comprendre que les URL des rendus, des images et d'autres ressources ne sont pas fixes. Brightcove reconfigure le stockage des ressources multimédias de temps en temps, et lorsque cela se produit, les URL des ressources spécifiques changent. Si vous comptez sur des URL codées en dur vers ces actifs dans vos pages ou applications, les liens se briseront à un moment donné.
De plus, toutes les URL contiennent un TTL jeton pour des raisons de sécurité du contenu. Cela signifie que les URL expirent après 6 heures par défaut. La durée de vie du token peut être prolongée jusqu'à 365 jours - si vous voulez des tokens à plus longue durée de vie, Contacter l'assistance Brightcove. Sachez toutefois que le TTL reflète la durée maximale pendant laquelle l'actif sera mis en cache par le CDN, mais ne garantit pas que l'URL ne changera pas avant l'expiration du jeton.
Pour le contenu VOD, vous pouvez spécifier un TTL plus court dans l'URL du manifeste. Pour plus de détails, voir le document Short Manifest TTL .
Le meilleur moyen d'empêcher la rupture des liens vers les médias est de les récupérer à partir de Video Cloud au moment de l'exécution en utilisant le API CMS ou la API de lecture.
Mettre en cache les URL
Si une demande d'API d'exécution n'est pas une option, nous vous recommandons d'obtenir les URL à partir d'un cache de données local qui est actualisé au moins une fois par jour, ou dans le délai de vie défini pour votre TTL jetons, selon le plus court.
URL statiques
Brightcove fournit des URL statiques vers des fichiers manifestes vidéo pour les ressources de votre bibliothèque Video Cloud. Cela vous donne la possibilité de gérer votre contenu dans votre propre CMS et de le diffuser à l'aide d'un schéma de sécurité personnalisé.
Ceci est important pour les clients qui ont une architecture existante qui n'autorise pas un appel d'API Playback avant d'avoir besoin des URL du manifeste. Le joueur peut également utiliser cette fonction, réduisant le temps de démarrage de la lecture en éliminant un appel.
Pour plus de détails, voir le document Static URL Delivery .
Manifeste court TTL
Dans le flux de travail de la lecture, le lecteur Brightcove appelle l'API de lecture (ou l'API Edge Auth) pour récupérer les manifestes disponibles afin de démarrer la lecture en fournissant une clé de stratégie (ou JWT) pour l'authentification.
Une couche de mise en cache a été introduite pour permettre à ces API de s'adapter et d'être hautement disponibles. Cette couche stocke les réponses de l'API URL du manifeste signé et de l'API de lecture. Comme les manifestes signés seront mis en cache, le TTL doit être suffisamment long pour être valide pendant la durée du cache, plus une mémoire tampon pour le lecteur.
Les TTL courts et manifestes permettent aux spectateurs de poursuivre la lecture sans encombre. En outre, toutes les fonctions de distribution dynamique fonctionnent avec le TTL à manifeste court.
Conflits d'ID de référence
Cette section s'applique à la CMS API seule.
Pour garantir l'unicité des identifiants de référence, l'identifiant CMS API verrouille l'id pendant 3 minutes au maximum après toute opération sur la vidéo à laquelle il est affecté. Cela peut entraîner le retour d'erreurs 409 lorsque vous essayez de réessayer une demande qui échoue trop rapidement, ou lorsque vous essayez de réutiliser un identifiant de référence trop tôt après avoir supprimé la vidéo à laquelle il était précédemment attribué. Voir le Référence des messages d'erreur pour plus de détails.