Einleitung
Sowohl die CMS- als auch die Wiedergabe-APIs bieten Zugriff auf Ihre Video Cloud-Videodaten. Der Zweck dieses Themas besteht darin, Ihnen zu helfen, den Unterschied zwischen ihnen und den Best Practices für ihre Verwendung zu verstehen.
Unterschiede zwischen CMS und Playback-APIs
Die CMS- und Playback-APIs greifen auf dieselben zugrunde liegenden Videodaten zu. Es gibt jedoch einige wichtige Unterschiede, die bestimmen sollten, welche Sie in bestimmten Situationen verwenden.
Generell ist die CMS API ist für die Verwendung im Backend vorgesehen, z. B. für die Integration von Video Cloud in Ihr CMS-System. Die Playback-API ist für die Frontend-Nutzung zum Abrufen von Video- und Playlist-Daten für Player oder Videoportale (der Brightcove Player catalog und playlist APIs verwenden beispielsweise die Playback-API).
In der folgenden Tabelle sind einige wichtige Unterschiede zwischen den beiden APIs aufgeführt.
| Artikel | CMS-API | Wiedergabe-API |
|---|---|---|
| Arten von Operationen | erstellen, lesen, aktualisieren, löschen | schreibgeschützt - keine Daten können mit der Playback-API geändert werden |
| Tätigkeitsbereich | Verwalten Sie jeden Aspekt Ihrer Videodaten | Rufe bestimmte Videos oder Playlists ab oder suche nach Videos |
| Authentifizierung | Vorübergehend Zugriffstoken | Dauerhaft Richtlinienschlüssel |
| Aktualität der Daten | Kein Caching, immer aktuell | Bis zu 20 Minuten im Cache |
| Reaktionsgeschwindigkeit | Langsamer | Schneller (wegen des Cachings) |
| Betreten | Nur serverseitig (CORs deaktiviert) | Server- oder clientseitig (CORs aktiviert) |
| Daten | Video- und Playlist-Anfragen enthalten keine Videoquell-URLs; eine zweite Anfrage ist erforderlich, um diese zu erhalten | Video- und Playlist-Anfragen enthalten Videoquell-URLs |
Verwenden von Medien-URLs
Es ist wichtig zu wissen, dass URLs für Wiedergaben, Bilder und andere Assets nicht festgelegt sind. Brightcove konfiguriert die Speicherung von Medienobjekten von Zeit zu Zeit neu. In diesem Fall ändern sich die URLs für bestimmte Objekte. Wenn Sie sich in Ihren Seiten oder Apps auf hartcodierte URLs zu diesen Assets verlassen, werden die Links irgendwann unterbrochen.
Außerdem enthalten alle URLs a TTL Token aus Gründen der Inhaltssicherheit. Das bedeutet, dass die URLs standardmäßig nach 6 Stunden ablaufen. Die Lebensdauer des Tokens kann auf bis zu 365 Tage verlängert werden - wenn Sie langlebigere Token wünschen, Brightcove-Support kontaktieren. Beachten Sie jedoch, dass die TTL spiegelt die maximale Zeit wider, die das Asset vom CDN zwischengespeichert wird, ist jedoch keine Garantie dafür, dass sich die URL nicht ändert, bevor das Token abläuft.
Für VOD-Inhalte können Sie eine kürzere TTL für die Manifest-URL angeben. Einzelheiten finden Sie unter Kurze Manifest-TTL dokumentieren.
Der beste Weg, um zu verhindern, dass Links zu Medien unterbrochen werden, besteht darin, sie zur Laufzeit mithilfe der CMS-API oder der Playback-API aus Video Cloud abzurufen.
Caching-URLs
Wenn eine Laufzeit-API-Anfrage keine Option ist, empfehlen wir, die URL(s) aus einem lokalen Datencache zu beziehen, der mindestens einmal täglich aktualisiert wird, oder innerhalb der für Sie festgelegten Lebensdauer TTL Token, je nachdem, welcher Wert kürzer ist.
Statische URLs
Brightcove stellt statische URLs für Videomanifestdateien für Assets in Ihrer Video Cloud-Bibliothek bereit. Dies gibt Ihnen die Flexibilität, Ihre Inhalte in Ihrem eigenen CMS zu verwalten und mit einem benutzerdefinierten Sicherheitsschema bereitzustellen.
Dies ist wichtig für Kunden, die über eine vorhandene Architektur verfügen, die keinen Aufruf der Playback-API zulässt, bevor die Manifest-URL(s) benötigt wird. Der Player kann diese Funktion auch verwenden, um die Startzeit der Wiedergabe zu reduzieren, indem ein Anruf entfällt.
Einzelheiten finden Sie unter Statische URL-Zustellung dokumentieren.
Kurzes Manifest TTL
Im Wiedergabeworkflow ruft der Brightcove-Player die Wiedergabe-API (oder Edge-Auth-API) auf, um die verfügbaren Manifeste zum Starten der Wiedergabe abzurufen, indem ein Richtlinienschlüssel (oder JWT) zur Authentifizierung bereitgestellt wird.
Damit diese APIs skalierbar und hochverfügbar sind, wurde eine Caching-Schicht eingeführt. Diese Schicht speichert die Antworten von der Signed Manifest URL API und der Playback API. Da die signierten Manifeste zwischengespeichert werden, muss die TTL lang genug sein, um für die Zeit im Cache gültig zu sein, plus einen Puffer für den Player.
Kurze Manifest-TTLs ermöglichen es den Zuschauern, die Wiedergabe ungehindert fortzusetzen. Außerdem funktionieren alle Funktionen der dynamischen Zustellung mit Short manifest TTL.
Konflikte mit der Referenz-ID
Dieser Abschnitt gilt für die CMS API nur.
Um die Eindeutigkeit von Referenz-IDs zu gewährleisten, wird die CMS API Sperrt die ID für bis zu 3 Minuten nach jeder Operation an dem Video, dem sie zugewiesen ist. Dies kann dazu führen, dass 409-Fehler zurückgegeben werden, wenn Sie versuchen, eine Anforderung zu wiederholen, die zu schnell fehlschlägt, oder wenn Sie versuchen, eine Referenz-ID zu früh nach dem Löschen des Videos, dem sie zuvor zugewiesen war, wiederzuverwenden. Siehe die Fehlermeldungsreferenz für mehr Details.