soporte Contactar con asistencia técnica | estado del sistema Estado del Sistema

Guía de aprendizaje: Uso de las API REST

En este tema, primero obtendrá una visión general de alto nivel sobre el uso de las API REST en aplicaciones web a través de XMLHttpRequest() y un proxy. Luego, más adelante en el documento, una inmersión más profunda analizará el código de ejemplo. El primer ejemplo usa el Analytics API para recuperar y mostrar en Brightcove player barra de control el número de vistas del video actualmente en el player ha tenido. El segundo ejemplo, y un poco más complejo, utiliza el Analytics API en conjunción con la Brightcove Player Catálogo para recuperar los videos más populares de una cuenta y mostrarlos en una lista de reproducción. La discusión del código en este documento se centrará en recuperar los datos deseados de la API REST correcta.

Vista de alto nivel

Para usar las API REST necesita tener algunas piezas en su lugar. En resumen, son:

  • Codigo del cliente: El código del cliente solicita datos específicos y luego los muestra según los requisitos de la aplicación. El código del cliente se tratará con cierta extensión en este documento, ya que es lo que necesitará escribir con más frecuencia.
  • Los servidores proxy: Por razones de seguridad, las API REST no aceptarán solicitudes de datos directamente del cliente, ya que eso alentaría el envío de información confidencial, como credenciales del cliente, desde el cliente. Esto significa que un proxy actuará como intermediario entre el cliente y la API REST. El proxy utilizado en los ejemplos está escrito en PHP y se analiza más adelante en este documento. El proxy debe configurarse en un servidor bajo su control, y puede escribirse en el idioma de su elección. La configuración sugerida del proxy le permite ser escrita una vez y utilizada por cualquiera de las API.
  • API REST: Brightcove proporciona un conjunto completo de API para personalizar, ampliar e integrar con la plataforma Brightcove. Ver el Características: Video Cloud API documento para más información.

El siguiente diagrama muestra la interacción entre las tres entidades centrales del proceso para recuperar datos de una de las API REST de Brightcove:

Descripción general de piezas básicas

Descripción de la funcionalidad del cliente

El código del lado del cliente cambia significativamente dependiendo de qué API está solicitando datos. Como se mencionó anteriormente, el proxy es una escritura única y no modifica el código, y Brightcove mantiene las API. Es por eso que el énfasis en el documento estará en aprender cómo alterar el código del cliente para recuperar los datos deseados de una de las API.

El siguiente diagrama se centra en las partes clave del código del cliente, que son:

  • La función que hace que HTTPRequest al proxy. Para evitar la ambigüedad, la función se llama makeRequest(). Está representado en el lado derecho del diagrama a continuación.
  • El código que reúne la información requerida para la solicitud. Está representado en la esquina superior izquierda del diagrama. Este código suele ser bastante sencillo y utiliza conceptos bien conocidos incluso para los programadores principiantes.
  • La llamada que ejecuta el mencionado anteriormente makeRequest() función. Está representado en la esquina inferior izquierda del diagrama. La llamada pasa una función a makeRequest() como un parámetro. Entonces en makeRequest() Esa función se llama. Este es un ejemplo de un anónimo definido. llamar de vuelta función.

Ves las dos secciones en el diagrama etiquetado Actividad asíncrona. Aunque se representa en el diagrama en dos lugares diferentes, esta es en realidad la misma actividad asincrónica, y representa el tiempo desconocido que requiere:

  • El cliente para enviar la solicitud al proxy.
  • El proxy para solicitar datos de la API.
  • La API para construir el conjunto de resultados y devolverlo al proxy.
  • El proxy para devolver los datos al cliente.

Tenga en cuenta que las flechas de flujo lógico del cuadro que llama makeRequest() (cuadro inferior izquierdo) parece indicar que el código se ejecuta en dos momentos diferentes, que es exactamente el caso. La llamada a la función se realiza, pero la función de devolución de llamada no se ejecuta hasta makeRequest() ha hecho su trabajo y se ejecuta la función de devolución de llamada, que devuelve los datos solicitados al código de llamada a la función.

Descripción de la funcionalidad del cliente

Ejemplo de código paso a paso

En lugar de mirar el código como una sola pieza, será presentado y discutido en secciones. Algunas de las secciones se relacionarán con el diagrama de arriba.

Estándar player código

Esta sección de código contiene el código básico. Brightcove Player código de inserción en la página.

  • Líneas 11-21: Estándar Brightcove Player código con la adición de una id atributo agregado.
	<!doctype html>
	<html>
	
	<head>
		<meta charset="UTF-8">
		<title>Untitled Document</title>
	</head>
	
	<body>
	
	<video-js id="myPlayerID"
		data-video-id="3851380732001"
		data-account="1752604059001"
		data-player="HkAzSmB0l"
		data-embed="default"
		data-application-id
		class="video-js"
		controls
		width="640"
		height="360"></video-js>
	<script src="https://players.brightcove.net/1752604059001/HkAzSmB0l_default/index.min.js"></script>

Preparándose para hacer una llamada

Esta sección de código inicializa las variables y se prepara para realizar la llamada a makeRequest(). En términos generales, para una solicitud de lectura deberá proporcionar la siguiente información:

  1. La URL del proxy que va a utilizar, por ejemplo (por supuesto, debe ser un proxy bajo su control):
    	https://solutions.brightcove.com/bcls/bcls-proxy/doc-samples-proxy-v2.php
  2. La URL necesaria para la solicitud real, normalmente construida dinámicamente:
    	https://analytics.api.brightcove.com/v1/alltime/accounts/1752604059001/videos/4825279519001
  3. El método HTTP, por ejemplo GET.

Un ejemplo a continuación:

  • Línea 1: Código estándar para esperar hasta player está listo para interactuar con
  • Líneas 2-4: crea / establece valores para las variables necesarias más adelante en el código.
  • Líneas 7-12: aguarde el loadstart evento por lo que el mediainfo objeto se rellena. Asignar variables para mantener los valores necesarios para el Analytics API punto final
  • Línea 13: establece el método HTTP para la llamada.
	videojs.getPlayer('myPlayerID').ready(function() {
	  var myPlayer = this,
		accountId = myPlayer.bcinfo.accountId,
		options = {};
	
		// +++ Wait for loadstart event so can use mediainfo object +++
		myPlayer.on('loadstart', function() {
			var videoId = myPlayer.mediainfo.id,
			baseURL = 'https://analytics.api.brightcove.com/v1/alltime/accounts/',
			endPoint = accountId + '/videos/' + videoId;
			options.proxyURL = "https://solutions.brightcove.com/bcls/bcls-proxy/doc-samples-proxy-v2.php";
			options.url = baseURL + endPoint;
			options.requestType = "GET";

Llamada makeRequest()

Esta sección de código hace que la llamada a makeRequest() función. Tenga en cuenta que se pasan dos parámetros. El primero es el objeto de opciones que contiene información para el punto final, y el segundo es la función de devolución de llamada. Recuerde, esta es una llamada asíncrona, por lo que la función de devolución de llamada definida anónimamente no se ejecutará hasta que la API REST haya devuelto los datos a la makeRequest() función.

  • Línea 1: llamar al makeRequest() función, pasando los valores requeridos para la llamada en el options objeto. En este caso, el objeto contiene lo siguiente:
    objeto de opciones
  • Líneas 3-13: la función de devolución de llamada se define como una función anónima (resaltada en amarillo). Recuerde que esta función es un parámetro y NO se llama aquí, sino más adelante en el código.
  • Líneas 6, 8, 10: console.log() declaraciones que muestran:
    • La cadena JSON sin procesar que devuelve la llamada API.
    • El objeto JSON generado por el JSON.parse() método que hace la conversión de cadena a objeto.
    • Las vistas reales cuentan, extraídas del objeto mediante el uso de simples object.property notación.
  • Línea 12: llama a la función que muestra el número de vistas en la barra de control.

La siguiente captura de pantalla de la consola muestra datos reales console.log declaraciones:

Procesamiento de datos en la función de devolución de llamada
	// +++ Make the request to the Analytics API +++
	// Extract views from data returned by Analytics API
	makeRequest(options, function(viewsRaw) {
	var viewsCount;
	// Remove console.log command for production code
	console.log('viewsRaw', viewsRaw);
	viewsObject = JSON.parse(viewsRaw);
	console.log('viewsObject', viewsObject);
	viewsCount = viewsObject.alltime_video_views;
	console.log('views', viewsCount);
	// Call function to place data in controlbar
	placeCountInControlbar(viewsCount);
	});

Real makeRequest() función

Esta sección del documento examina el código que realmente define el makeRequest() función. El código que define la función está escrito de tal manera que NO necesita ser modificado, sino usado repetidamente tal como está. Puede encontrar casos extremos de que esto no es cierto, pero para la gran mayoría de los usos, este código NO necesita ser modificado.

Sigue una discusión línea por línea del código:

  • Líneas 1-6: Definición de funciones y creación de variables. Un punto clave es que un nuevo XMLHttpRequest el objeto es creado
  • Líneas 8, 26: define la función del controlador de eventos para readyState cambios.
  • Líneas 9, 23, 25: Use una try-catch en caso de que la solicitud falle en un nivel alto.
  • Líneas 10, 11: uso if declaraciones para asegurarse de que la solicitud haya finalizado (readyState es 4) y se completó con éxito, el estado está en el rango 200. A continuación, se muestra el registro de la consola del readyState y status valores en la definición del controlador de eventos:
    Logging readyState y estado
  • Línea 18: la función de devolución de llamada se ejecuta. Esto pasa los datos devueltos de la API a la función de devolución de llamada como se detalla en el Llamar a makeRequest () la sección de arriba.
  • Line 33: establece el controlador de eventos para el XMLHttpRequest.onreadystatechange evento.
  • Línea 35: Inicializa la solicitud al proxy.
  • Línea 38: envía la solicitud, que es asincrónica.
	function makeRequest(options, callback) {
	var httpRequest = new XMLHttpRequest(),
	response,
	requestParams,
	dataString,
	proxyURL = options.proxyURL,
	// response handler
	getResponse = function() {
	try {
		if (httpRequest.readyState === 4) {
			if (httpRequest.status >= 200 && httpRequest.status < 300) {
				response = httpRequest.responseText;
				// some API requests return '{null}' for empty responses - breaks JSON.parse
				if (response === '{null}') {
					response = null;
				}
				// return the response
				callback(response);
			} else {
				alert('There was a problem with the request. Request returned ' + httpRequest.status);
			}
		}
	} catch (e) {
		alert('Caught Exception: ' + e);
	}
	};
	/**
	* set up request data
	* the proxy used here takes the following request body:
	* JSON.stringify(options)
	*/
	// set response handler
	httpRequest.onreadystatechange = getResponse;
	// open the request
	httpRequest.open('POST', proxyURL);
	// set headers if there is a set header line, remove it
	// open and send request
	httpRequest.send(JSON.stringify(options));
	}

Mostrar los datos devueltos

Este código muestra cómo colocar los datos devueltos en la barra de control. Esta función se llama al final de la función de devolución de llamada, que se muestra en Llamar a makeRequest () la sección de arriba.

  • Líneas 5, 16: define la función.
  • Línea 6: crea una variable para spacer elemento en la barra de control.
  • Line 7: crea dinámicamente un div elemento.
  • Línea 9: Coloque una etiqueta y el valor de las vistas en el recién creado div elemento.
  • Línea 11: use JavaScript document.getElementsByClassName() método para obtener la barra de control spacer elemento.
  • Línea 13: estilo el spacer para mostrar el total de vistas justificadas a la derecha y hacia abajo 10px desde la parte superior de la spacer.
  • Línea 15: agregue el elemento recién creado, poblado y estilo al spacer.
	/**
	* Dynamically build a div that is then
	* placed in the controlbar's spacer element
	*/
	function placeCountInControlbar(viewsCount) {
	var spacer,
	newElement = document.createElement('div');
	//Place data in div
	newElement.innerHTML = "Total Views: " + viewsCount;
	//Get the spacer in the controlbar
	spacer = document.getElementsByClassName('vjs-spacer')[0];
	//Right justify content in the spacer and add top margin
	spacer.setAttribute('style', 'justify-content: flex-end; margin-top: 10px');
	//Add the dynamically built div to the spacer in the controlbar
	spacer.appendChild(newElement);
	}

Completar el listado de códigos

El código completo y funcional se encuentra en este repositorio de GitHub: display-views-in-controlbar.html.

Depuración simple

Como puede ver, hay varias piezas involucradas al usar las API REST. Esto puede presentar desafíos cuando una aplicación no funciona correctamente. ¿Dónde empiezas a depurar?

En esta sección se hacen un par de sugerencias simples y son un excelente lugar para comenzar su aventura de depuración. Las siguientes dos secciones le brindan una manera de ver la información más básica que necesita, qué se transmite para realizar la llamada y qué se devuelve.

Comprobando las opciones de llamada

El código del lado del cliente que se analiza en este documento tiene que ver básicamente con proporcionar las opciones correctas que se utilizarán con el proxy y, a su vez, la API real. Por lo tanto, saber que las opciones son correctas es esencial para el correcto funcionamiento de su código. Una forma sencilla de hacer esto es registrar en la consola el options objeto justo antes de que pasen a la makeRequest Función donde se utilizan:

opciones de registro de código de depuración

Lo que contiene el objeto de opciones variará según lo que intente hacer, pero siempre habrá algunos conceptos básicos, que son:

  • El ID de la cuenta. Esto puede ser una propiedad separada o parte de la URL del punto final de la API.
  • La URL del proxy, que dependerá de dónde almacene su proxy.
  • El tipo de método HTTP, por ejemplo GET, POST or PATCH.
  • La URL de punto final de API utilizada por el proxy para realizar la solicitud real desde la API. Por ejemplo:
    	https://players.api.brightcove.com/v2/accounts/57838016001/players
    	https://edge.api.brightcove.com/playback/v1/accounts/1752604059001/videos/5842800655001
    	https://analytics.api.brightcove.com/v1/alltime/accounts/1752604059001/videos/4093643993001

Se pueden requerir otras propiedades en el objeto de opciones según la solicitud de API. Aquí hay un ejemplo de lo que vería en la consola al registrar el objeto de opciones para realizar una solicitud de todos los players en una cuenta específica:

opciones de depuración simples

Aquí hay un objeto de opciones de registro un poco más complejo que se usa al actualizar players:

opciones de depuración

Viendo los datos devueltos

Lo que se devuelve variará según los datos que haya solicitado, y si se devuelve un error. Pero independientemente de lo que se devuelva, lo más probable es que desee ver qué datos se devuelven. Una forma sencilla de hacer esto es registrar en la consola el raw response datos justo después de la llamada a la makeRequest función:

opciones de registro de código de depuración

Lo que se devolverá tiene posibilidades casi infinitas, pero los siguientes son algunos ejemplos. El primero muestra el comienzo de una respuesta al preguntar por todos los players en una cuenta:

respuesta de depuración en players solicitud

Aquí está la respuesta después de actualizar players, usando el PATCH Método HTTP:

respuesta de depuración en player parche

Aquí hay una vista con un formato más agradable de los datos en la primera respuesta:

	{
		"id": "1OHQdsTAr",
		"preview_url": "http://preview-players.brightcove.net/v2/accounts/.../master/index.html",
		"preview_embed_in_page": "http://preview-players.brightcove.net/v2/accounts/.../master/in_page.embed",
		"preview_embed_code": "<iframe src='//preview-players.brightcove.net/v2/accounts/.../master/index.html' ...></iframe>"
	}

Y finalmente, aquí hay una respuesta muy valiosa de cuando ocurrió un error. En este caso, se estaba utilizando una cuenta sin las credenciales adecuadas:

respuesta de depuración en error

Otros consejos para solucionar problemas

Si tiene problemas, aquí hay otras cosas que debe buscar.

Obteniendo ninguna respuesta
Hay un par de cosas para verificar si obtiene una respuesta vacía:
  • Verifique la referencia de la API para asegurarse de que la solicitud devuelva una respuesta. Algunos solo devuelven una respuesta 201 o 204 sin contenido (especialmente, pero no solo, las solicitudes DELETE). Tendrá que ajustar su código para manejar este caso.
  • Verifique la sección Red de las Herramientas de desarrollo en su navegador para asegurarse de que ve una llamada exitosa al proxy (ese servidor podría no estar disponible temporalmente):
    Sección de red de herramientas para desarrolladores
    Sección de red de herramientas para desarrolladores
Veo una respuesta, pero cuando intento JSON.parse() eso, me sale una excepción.
Algunas posibilidades aquí:
  • Vea el elemento anterior: intentar analizar una cadena vacía generará una excepción JSON
  • Mire la respuesta y asegúrese de que sea una cadena JSON (que comienza con una { o una [). Hay algunos casos en los que una solicitud podría no devolver JSON: un Analytics API llame, por ejemplo, si configura el format parámetro para csv or xlxs. Nuevamente, si realiza ese tipo de solicitudes, deberá ajustar su código para manejar respuestas que no sean JSON.

  • En la mayoría de los casos, los errores devueltos por las API también están en formato JSON, pero hay algunas excepciones donde el error se devuelve como texto sin formato o HTML.

Código proxy

Como se mencionó anteriormente, el proxy se puede escribir en el idioma que elija. Los ejemplos de documentación de la API de Brightcove utilizan un proxy escrito en PHP. Dado que la implementación del proxy depende mucho del idioma, el siguiente código PHP no se analizará en detalle en este documento.

La funcionalidad básica proporcionada por un proxy debe incluir:

  1. Aceptar la solicitud del cliente
  2. conseguir una token de autenticación de la OAuth API.
  3. Envíe el token de autenticación y la solicitud de datos (punto final) a la API deseada.
  4. Reciba datos de API.
  5. Enviar datos de vuelta al cliente.
	<?php
	/**
	 * proxy for Brightcove RESTful APIs
	 * gets an access token, makes the request, and returns the response
	 * Accessing:
	 *     (note you should **always** access the proxy via HTTPS)
	 *     Method: POST
	 *     request body (accessed via php://input) is a JSON object with the following properties
	 *
	 * {string} url - the URL for the API request
	 * {string} [requestType=GET] - HTTP method for the request
	 * {string} [requestBody] - JSON data to be sent with write requests
	 * {string} [client_id] - OAuth2 client id with sufficient permissions for the request
	 * {string} [client_secret] - OAuth2 client secret with sufficient permissions for the request
	 *
	 * Example:
	 * {
	 *    "url": "https://cms.api.brightcove.com/v1/accounts/57838016001/video",
	 *    "requestType": "PATCH",
	 *    "client_id": "0072bebf-0616-442c-84de-7215bb176061",
	 *    "client_secret": "7M0vMete8vP_Dmb9oIRdUN1S5lrqTvgtVvdfsasd",
	 *    "requestBody": "{\"description\":\"Updated video description\"}"
	 * }
	 *
	 * if client_id and client_secret are not included in the request, default values will be used
	 *
	 * @returns {string} $response - JSON response received from the API
	 */
	
	// security checks
	// if you want to do some basic security checks, such as checking the origin of the
	// the request against some white list, this would be a good place to do it
	// CORS enablement and other headers
	header("Access-Control-Allow-Origin: *");
	header("Content-type: application/json");
	header("X-Content-Type-Options: nosniff");
	header("X-XSS-Protection");
	
	// default account values
	// if you work on one Brightcove account, put in the values below
	// if you do not provide defaults, the client id, and client secret must
	// be sent in the request body for each request
	$default_client_id     = 'YOUR_CLIENT_ID';
	$default_client_secret = 'YOUR_CLIENT_SECRET';
	
	// get request body
	$requestData = json_decode(file_get_contents('php://input'));
	
	// set up access token request
	// check to see if client id and secret were passed with the request
	// and if so, use them instead of defaults
	if (isset($requestData->client_id)) {
			$client_id = $requestData->client_id;
	}
	
	if (isset($requestData->client_secret)) {
			$client_secret = $requestData->client_secret;
	}
	
	$auth_string = "{$client_id}:{$client_secret}";
	
	// make the request to get an access token
	$request = "https://oauth.brightcove.com/v4/access_token?grant_type=client_credentials";
	$curl          = curl_init($request);
	curl_setopt($curl, CURLOPT_USERPWD, $auth_string);
	curl_setopt($curl, CURLOPT_POST, TRUE);
	curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE);
	curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
	curl_setopt($curl, CURLOPT_HTTPHEADER, array(
		'Content-type: application/x-www-form-urlencoded',
	));
	
	$response = curl_exec($curl);
	$curl_info = curl_getinfo($curl);
	$php_log = array(
		"php_error_info" => $curl_info
	);
	$curl_error = curl_error($curl);
	
	curl_close($curl);
	
	// Check for errors
	// it's useful to log as much info as possible for debugging
	if ($response === FALSE) {
		log_error($php_log, $curl_error);
	}
	
	// Decode the response and get access token
	$responseData = json_decode($response, TRUE);
	$access_token = $responseData["access_token"];
	// get request type or default to GET
	$method = "GET";
	if ($requestData->requestType) {
			$method = $requestData->requestType;
	}
	
	// get the URL and authorization info from the form data
	$request = $requestData->url;
	// check for a request body sent with the request
	if (isset($requestData->requestBody)) {
		$data = $requestData->requestBody;
	}
		$curl = curl_init($request);
		curl_setopt($curl, CURLOPT_RETURNTRANSFER, TRUE);
		curl_setopt($curl, CURLOPT_SSL_VERIFYPEER, FALSE);
		curl_setopt($curl, CURLOPT_HTTPHEADER, array(
			'Content-type: application/json',
			"Authorization: Bearer {$access_token}"
		));
		switch ($method)
			{
				case "POST":
					curl_setopt($curl, CURLOPT_POST, TRUE);
					if ($requestData->requestBody) {
						curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
					}
					break;
				case "PUT":
					// don't use CURLOPT_PUT; it is not reliable
					curl_setopt($curl, CURLOPT_CUSTOMREQUEST, $method);
					if ($requestData->requestBody) {
						curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
					}
					break;
				case "PATCH":
					curl_setopt($curl, CURLOPT_CUSTOMREQUEST, $method);
					if ($requestData->requestBody) {
						curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
					}
					break;
				case "DELETE":
					curl_setopt($curl, CURLOPT_CUSTOMREQUEST, $method);
					if ($requestData->requestBody) {
						curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
					}
					break;
				default:
					// GET request, nothing to do;
			}
		$response = curl_exec($curl);
		$curl_info = curl_getinfo($curl);
		$php_log = array(
			"php_error_info" => $curl_info
		);
		$curl_error = curl_error($curl);
		curl_close($curl);
	
	// Check for errors and log them if any
	// note that logging will fail unless
	// the file log.txt exists in the same
	// directory as the proxy and is writable
	
	if ($response === FALSE) {
		log_error($php_log, $curl_error);
	}
	
	function log_error($php_log, $curl_error) {
		$logEntry = "\nError:\n". "\n".date("Y-m-d H:i:s"). " UTC \n" .$curl_error. "\n".json_encode($php_log, JSON_PRETTY_PRINT);
		$logFileLocation = "log.txt";
		$fileHandle      = fopen($logFileLocation, 'a') or die("-1");
		fwrite($fileHandle, $logEntry);
		fclose($fileHandle);
		echo "Error: there was a problem with your API call"+
		die(json_encode($php_log, JSON_PRETTY_PRINT));
	}
	
	// return the response to the AJAX caller
	echo $response;
	?>

Aunque el código completo para el servidor proxy se muestra arriba, también se encuentra en el repositorio de GitHub: aplicaciones de muestra de proxy en el objeto php carpeta.

ejemplo 2

Este segundo ejemplo es más complejo que el detallado anteriormente. Este ejemplo muestra los videos 10 más populares de una cuenta en una lista de reproducción. Los principales pasos del código son:

  1. Solicitud del Analytics API Los videos 10 con la mayor cantidad de vistas en una cuenta. Este paso implica una llamada asíncrona mediante una función de devolución de llamada.
  2. De la vuelta Analytics API datos, extraiga solo las ID de video y colóquelas en una matriz. Se escribe una función auxiliar para realizar la extracción de ID de los datos devueltos.
  3. Solicite los objetos de video completos para cada uno de los videos en la lista de ID de la matriz. Este paso implica recorrer el conjunto y solicitar que los objetos de video utilicen player.catalog.getVideo(). Por supuesto, esto implica múltiples llamadas asincrónicas usando el catalog. Se escribe una función auxiliar para recuperar los objetos de video basados ​​en ID y colocar los objetos en una matriz.
  4. Coloque la matriz de objetos de video en la lista de reproducción para una lista de reproducción habilitada player.

Como ahora está familiarizado con muchos de los conceptos y códigos específicos sobre cómo llamar a las API, solo el código que llama al makeRequest() la función es detallada.

  • Línea 2: llamar al makeRequest() función que pasa como argumentos las opciones necesarias para una exitosa llamada a la API REST, junto con una función de devolución de llamada definida anónimamente (resaltada en amarillo). Esto debería sonarle familiar desde arriba. Muy importante, el makeRequest() función que se llama ES LA MISMA FUNCIÓN EXACTA UTILIZADA EN EL EJEMPLO ANTERIOR. Puedes hacer lo mismo en tu código. los makeRequest() La función se escribió para ser reutilizada con cualquier llamada a una API REST de Brightcove.
  • Línea 3: crea una variable para contener los datos devueltos analizados por JSON.
  • Línea 5: analiza los datos devueltos para convertir si de una cadena a un objeto.
  • Línea 7: use la función de ayuda para extraer las ID de video de los datos devueltos. Desafortunadamente, el Analytics API no devuelve los objetos de video completos, por lo que se necesitan ID para acceder a los objetos completos.
  • Líneas 9-12: llame al getVideoData función de ayuda que usa una función de devolución de llamada para poblar el videoObjects matriz basada en ID pasados.
  • Línea 11: llena la lista de reproducción con la matriz de objetos de video.
	// +++ Make the CMS API request to get matching video IDs +++
	makeRequest(options, function(mostWatchedVideos) {
		var JSONmostWatchedVideos;
		// Convert response string into JSON
		JSONmostWatchedVideos = JSON.parse(mostWatchedVideos);
		// Extract the needed video IDs into an array
		videoData = extractVideoData(JSONmostWatchedVideos);
		// Get video objects based on array of video IDs
		getVideoData(videoData, function(videoObjects) {
			// Add the most watched videos list to the player as a playlist
			myPlayer.playlist(videoObjects);
		});
	});

Completar el listado de códigos

El ejemplo completo y funcional se encuentra en este CodePen: Videos más vistos en una lista de reproducción.


Página actualizada por última vez el 12 jun 2020