Lista de comprobación de API de REST V2 rest-api-v2-checklist

Requisitos

Riesgos

Utilice una aplicación registrada con el ámbito de API de REST v2.

Riesgos que activan respuestas de error "no autorizadas" HTTP 401, sobrecarga de recursos del sistema y aumento de la latencia.

Almacene las credenciales del cliente en un almacenamiento persistente y vuelva a utilizarlas para cada solicitud de token de acceso.

Corre el riesgo de perder la autenticación cuando se regeneran las credenciales del cliente.

Almacene los tokens de acceso en un almacenamiento persistente y vuelva a utilizarlos hasta que caduquen.

No solicite un nuevo token para cada llamada a la API REST v2, actualice los tokens de acceso solo cuando caduquen.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Requisitos

Riesgos

Recupere la respuesta de configuración solo cuando sea necesario solicitar al usuario que seleccione su MVPD (proveedor de TV) antes de la fase de autenticación.

No es necesario recuperar la respuesta de configuración cuando:

• El usuario ya se ha autenticado.
• Se ofrece acceso temporal al usuario.
• La autenticación del usuario ha caducado, pero se puede pedir al usuario que confirme que sigue siendo suscriptor del MVPD seleccionado anteriormente.

Riesgos de sobrecarga de recursos del sistema y aumento de la latencia.

Almacene la selección del proveedor de TV de pago (MVPD) del usuario en un almacenamiento persistente para utilizarlo en todas las fases posteriores:

• En el almacén de respuestas de configuración, el usuario seleccionó "id" de MVPD.
• En el almacén de respuestas de configuración, el usuario seleccionó MVPD "displayName".
• En el almacén de respuestas de configuración, el usuario seleccionó MVPD "logoUrl".

Riesgos de sobrecarga de recursos del sistema y aumento de la latencia.

Requisitos

Riesgos

Inicie el mecanismo de sondeo en las siguientes condiciones:

Autenticación realizada en la aplicación principal (pantalla)

• La aplicación principal (streaming) debe comenzar a sondear cuando el usuario llega a la página de destino final, después de que el componente del explorador cargue la URL especificada para el parámetro "redirectUrl" en la solicitud de extremo de sesiones.

Autenticación realizada en una aplicación secundaria (pantalla)

• La aplicación principal (streaming) debe iniciar el sondeo en cuanto el usuario inicie el proceso de autenticación, justo después de recibir la respuesta de extremo de sesiones y mostrar el código de autenticación al usuario.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Detener el mecanismo de sondeo en las siguientes condiciones:

Autenticación correcta

• La información de perfil del usuario se ha recuperado correctamente, lo que confirma su estado de autenticación y, por lo tanto, ya no es necesario realizar encuestas.

Sesión de autenticación y caducidad del código

• La sesión de autenticación y el código caducan, el usuario debe reiniciar el proceso de autenticación y el sondeo con el código de autenticación anterior debe detenerse inmediatamente.

Nuevo código de autenticación generado

• Si el usuario solicita un nuevo código de autenticación, la sesión existente se invalida y el sondeo que utiliza el código de autenticación anterior debe detenerse inmediatamente.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Configure la frecuencia del mecanismo de sondeo en las siguientes condiciones:

Autenticación realizada en la aplicación principal (pantalla)

• La aplicación principal (streaming) debe sondear cada 3-5 segundos o más.

Autenticación realizada en una aplicación secundaria (pantalla)

• La aplicación principal (streaming) debe sondear cada 3-5 segundos.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Almacene partes de la información de perfil del usuario en un almacenamiento persistente para mejorar el rendimiento y minimizar las llamadas innecesarias a la API de REST v2.

El almacenamiento en caché debe centrarse en los siguientes campos de respuesta de perfiles:

mvpd

• La aplicación cliente puede utilizar esto para realizar un seguimiento del proveedor de TV seleccionado del usuario y seguir utilizándolo durante las fases de preautorización o autorización.
• Cuando caduca el perfil de usuario actual, la aplicación cliente puede utilizar la selección de MVPD que se recuerda y solo pedirle que confirme.

atributos

• Se utiliza para personalizar la experiencia del usuario en función de diferentes claves de metadatos de usuario (por ejemplo, zip, maxRating, etc.).
• Los metadatos del usuario están disponibles una vez finalizado el flujo de autenticación, por lo que la aplicación cliente no necesita consultar un extremo independiente para recuperar la información de metadatos del usuario, ya que ya se incluye en la información del perfil.
• Algunos atributos de metadatos se pueden actualizar durante la fase de autorización, según el MVPD (por ejemplo, Charter) y el atributo de metadatos específico (por ejemplo, householdID). Como resultado, es posible que la aplicación cliente necesite volver a consultar las API de perfiles después de la autorización para recuperar los metadatos de usuario más recientes.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Requisitos

Riesgos

Utilice decisiones de autorización previa para el filtrado de contenido, nunca para las decisiones de reproducción.

Corre el riesgo de incumplir los acuerdos contractuales entre el programador, las MVPD y Adobe.

Riesgos que se saltan nuestros sistemas de monitoreo y alerta.

Gestione correctamente los códigos de error mejorados y utilice el campo de acción para determinar los pasos de corrección necesarios.

Solo un número limitado de códigos de error mejorados justifica un reintento, mientras que la mayoría requiere resoluciones alternativas, como se especifica en el campo de acción.

Asegúrese de que cualquier mecanismo de reintentos implementado para recuperar decisiones de preautorización no resulte en un bucle interminable y de que limite los reintentos a un número razonable (es decir, 2-3).

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Almacene en caché las decisiones correctas de permisos en la memoria para mejorar el rendimiento y minimizar las llamadas innecesarias a la API de REST v2, ya que las actualizaciones de suscripción mientras la aplicación se está ejecutando son poco frecuentes.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Requisitos

Riesgos

Obtener decisiones de autorización antes de la reproducción, independientemente de si existe una decisión de preautorización.

Permita que los flujos continúen sin interrupciones aunque el token de medios caduque durante la reproducción y solicite una nueva decisión de autorización que contenga un token de medios (nuevo) cuando el usuario realice su siguiente solicitud de reproducción, independientemente de si es para el mismo recurso o para uno diferente.

Las transmisiones en vivo que se ejecuten por períodos prolongados de tiempo pueden optar por solicitar una nueva decisión de autorización después de las operaciones de vídeo como pausar contenido, iniciar pausas comerciales o modificar configuraciones de nivel de recursos cuando el MRSS experimenta cambios.

Corre el riesgo de incumplir los acuerdos contractuales entre el programador, las MVPD y Adobe.

Riesgos que se saltan nuestros sistemas de monitoreo y alerta.

Gestione correctamente los códigos de error mejorados y utilice el campo de acción para determinar los pasos de corrección necesarios.

Solo un número limitado de códigos de error mejorados justifica un reintento, mientras que la mayoría requiere resoluciones alternativas, como se especifica en el campo de acción.

Asegúrese de que cualquier mecanismo de reintentos implementado para recuperar decisiones de autorización no resulte en un bucle interminable y de que limite los reintentos a un número razonable (es decir, 2-3).

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Requisitos

Riesgos

Implemente la API de cierre de sesión para permitir que los usuarios cierren sesión manualmente, finalizando su perfil autenticado y siguiendo el nombre de acción de la API de REST v2 especificado para cada perfil eliminado:

• Para las MVPD que admiten un extremo de cierre de sesión, la aplicación cliente requiere navegar a la "url" proporcionada en un user-agent.
• Para perfiles de tipo "appleSSO", la aplicación cliente requiere guiar al usuario para que también cierre la sesión desde el nivel de socio (configuración del sistema de Apple).

Corre el riesgo de que la aplicación cliente no funcione correctamente debido a la falta de compatibilidad en la aplicación cliente.

Requisitos

Riesgos

Envíe el encabezado Authorization para cada solicitud de API de REST v2.

Riesgos que activan respuestas de error "no autorizadas" HTTP 401, sobrecarga de recursos del sistema y aumento de la latencia.

Envíe el encabezado AP-Device-Identifier para cada solicitud de API de REST v2.

Incluso cuando la solicitud se origina desde un servidor en nombre de un dispositivo, el valor del encabezado AP-Device-Identifier debe reflejar el identificador real del dispositivo de flujo continuo.

Riesgos que activan respuestas de error HTTP 400 "Solicitud incorrecta", sobrecargan recursos del sistema y aumentan la latencia.

Envíe el encabezado X-Device-Info para cada solicitud de API de REST v2.

Incluso cuando la solicitud se origina desde un servidor en nombre de un dispositivo, el valor del encabezado X-Device-Info debe reflejar la información real del dispositivo de flujo continuo.

Los riesgos se clasifican como procedentes de una plataforma desconocida y se tratan como inseguros, y se someten a reglas más restrictivas, como TTL de autenticación más cortos.

Además, algunos campos, como el dispositivo de transmisión connectionIp y connectionPort, son obligatorios para características como la autenticación de base de inicio de Spectrum.

Calcule y almacene un identificador de dispositivo estable que no cambie al actualizar o reiniciar el encabezado AP-Device-Identifier.

En plataformas sin identificador de hardware, genere un identificador único a partir de los atributos de la aplicación y manténgalo.

Corre el riesgo de perder la autenticación cuando cambia el identificador del dispositivo.

Asegúrese de que solo envía los parámetros y encabezados esperados de la API de REST v2.

Riesgos que activan respuestas de error HTTP 400 "Solicitud incorrecta", sobrecargan recursos del sistema y aumentan la latencia.

Requisitos

Riesgos

Gestione correctamente los códigos de error mejorados y utilice el campo de acción para determinar los pasos de corrección necesarios.

Solo un número limitado de códigos de error mejorados justifica un reintento, mientras que la mayoría requiere resoluciones alternativas, como se especifica en el campo de acción.

Los códigos de error más mejorados enumerados en la documentación de Códigos de error mejorados - API REST V2 se pueden evitar por completo si se administran correctamente durante la fase de desarrollo antes de iniciar la aplicación.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Corre el riesgo de que la aplicación cliente no funcione correctamente debido a la falta de administración de los códigos de error mejorados, lo que provoca mensajes de error poco claros, instrucciones incorrectas del usuario o un comportamiento de reserva incorrecto.

Diferenciar entre la gestión de respuestas de error HTTP (por ejemplo, 400, 401, 403, 404, 405, 500) y respuestas de éxito (por ejemplo, 200, 201) que contienen cargas de códigos de error mejorados, como se ha indicado anteriormente.

Solo un número limitado de códigos de error HTTP justifica un reintento, mientras que la mayoría requiere resoluciones alternativas.

La mayoría de las respuestas de error HTTP se pueden evitar por completo si se administran correctamente durante la fase de desarrollo antes de iniciar la aplicación.

Se corre el riesgo de sobrecargar recursos del sistema, aumentar la latencia y activar potencialmente respuestas de error HTTP 429 "Demasiadas solicitudes".

Corre el riesgo de que la aplicación cliente no funcione correctamente debido a la falta de administración de los códigos de error mejorados, lo que provoca mensajes de error poco claros, instrucciones incorrectas del usuario o un comportamiento de reserva incorrecto.

Requisitos

Riesgos

Desarrolle y pruebe la aplicación con los entornos oficiales de no producción de autenticación de Adobe Pass:

• Prequal-Production
• Release-Staging

Realice un control de calidad exhaustivo (QA) en estos entornos antes de iniciar Release-Production.

Las aplicaciones cliente no deben continuar con Release-Production sin completar primero la validación de extremo a extremo en entornos que no sean de producción.

Se arriesga a lanzarse con defectos críticos y graves.

La falta de una ruta de depuración corta y eficaz puede impedir que el equipo de ingeniería y soporte técnico de Adobe intervenga con rapidez.

Prácticas

Riesgos

Compruebe de forma proactiva la validez del token de acceso para actualizarlo cuando caduque.

Asegúrese de que cualquier mecanismo de reintento para controlar los errores "no autorizados" de HTTP 401 actualice primero el token de acceso antes de volver a intentar la solicitud original.

Riesgos que activan respuestas de error "no autorizadas" HTTP 401, sobrecarga de recursos del sistema y aumento de la latencia.

Prácticas

Riesgos

Almacene la respuesta de configuración en la memoria o en el almacenamiento persistente durante un corto periodo de tiempo (por ejemplo, de 3 a 5 minutos) para mejorar el rendimiento y minimizar las llamadas innecesarias a la API de REST v2.

Riesgos de sobrecarga de recursos del sistema y aumento de la latencia.

Prácticas

Riesgos

Valide el código de autenticación enviado a través de los datos proporcionados por el usuario en la segunda aplicación (pantalla) secundaria antes de llamar a la API /api/v2/authenticate con las siguientes condiciones:

Autenticación realizada en la aplicación secundaria (pantalla) con mvpd preseleccionado

• Use Reanudar sesión de autenticación - POST /api/v2/{serviceProvider}/session/{code}

Autenticación realizada en una aplicación secundaria (pantalla) sin mvpd preseleccionado

• Use Recuperar sesión de autenticación - GET /api/v2/{serviceProvider}/session/{code}

La aplicación cliente recibiría un error si el código de autenticación proporcionado se escribía incorrectamente o en caso de que la sesión de autenticación caducara.

Arriesga varias respuestas de error y problemas de flujo de trabajo durante la autenticación.

Asegúrese de que la aplicación cliente pueda gestionar varios perfiles pidiéndole al usuario que seleccione un perfil o aplicando lógica personalizada, como seleccionar automáticamente el perfil con el periodo de validez más largo.

Corre el riesgo de que la aplicación cliente no funcione correctamente debido a la falta de compatibilidad en la aplicación cliente.

Admitir flujos no básicos en caso de que el negocio de las aplicaciones cliente requiera lo siguiente:

• Flujos de acceso degradados (función Premium)
• Flujos de acceso temporales (función Premium)
• Flujos de acceso de inicio de sesión único (función estándar)

Corre el riesgo de crear una experiencia de usuario menos que ideal.

Prácticas

Riesgos

Muestre comentarios claros del usuario si se rechaza una decisión de preautorización, utilizando la mensajería proporcionada por MVPD o Adobe a través de códigos de error mejorados.

Corre el riesgo de crear una experiencia de usuario menos que ideal.

Prácticas

Riesgos

Valide tokens de medios usando la biblioteca Verificador de token de medios.

Riesgos de esquemas de fraude como la extracción de flujos.

Muestre comentarios claros del usuario si se rechaza una decisión de autorización, utilizando la mensajería proporcionada por MVPD o Adobe a través de códigos de error mejorados.

Corre el riesgo de crear una experiencia de usuario menos que ideal.

Prácticas

Riesgos

Evite llamar automáticamente (mediante programación) a la API de cierre de sesión en situaciones como la denegación de autorización o preautorización, ya que la API de cierre de sesión solo debe invocarse en respuesta a una solicitud directa del usuario.

Se corre el riesgo de confundir al usuario de que la autenticación esté fallando.

Prácticas

Riesgos

Reutilice el código de la API de REST v1 para calcular el identificador del dispositivo y la información del dispositivo con ajustes menores, pero asegúrese de que solo envía los parámetros y encabezados esperados de la API de REST v2.

Vuelva a utilizar el código de la API de REST v1 para llamar a la API de DCR y recuperar un token de acceso.

-

Prácticas

Riesgos

Asegúrese de que los siguientes flujos básicos se prueben en todos los dispositivos y plataformas:

Flujos de autenticación

• Escenario de autenticación de la aplicación principal (pantalla)
• Escenario de autenticación de la aplicación secundaria (pantalla)

(Opcional) Flujos de preautorización

• Escenario de decisiones de permiso de prueba
• Escenario de decisiones de denegación de prueba

Flujos de autorización

• Escenario de decisiones de permiso de prueba
• Escenario de decisiones de denegación de prueba

Flujos de cierre de sesión

Además, pruebe otros flujos de acceso, si corresponde:

• Flujos de acceso degradados (función Premium)
• Flujos de acceso temporales (función Premium)
• Flujos de acceso de inicio de sesión único (función estándar)

Incluya las principales integraciones de MVPD (que abarcan los proveedores más utilizados).

Se arriesga a fallos imprevistos en la producción, especialmente en plataformas que se prueban con menor frecuencia o en flujos excepcionales como escenarios negativos.

Usar el sitio web Adobe Developer.

-

Fase

Obligatorio

(Muy) Recomendado

Credenciales de cliente de caché

Tokens de acceso de caché

Validación y actualización de tokens de acceso

Minimizar recuperaciones de respuestas de configuración

Respuesta de configuración de caché

Ajuste fino del mecanismo de sondeo

Partes de caché de perfiles

Admitir varios perfiles

Admitir característica de degradación (si es necesario para la empresa)

Admitir característica TempPass (si es necesario para la empresa)

Admitir característica de inicio de sesión único (si es necesario para la empresa)

Caché que permite decisiones de preautorización

Reintentar el ajuste del mecanismo

Mejorar la experiencia del usuario mediante el uso de códigos de error para las decisiones de preautorización denegadas

Recuperar decisión de autorización cuando el usuario solicita la reproducción

Reintentar ajuste del mecanismo

Mejore la experiencia del usuario utilizando códigos de error para las decisiones de autorización denegadas

Validación de token de medios

Implementar la API de cierre de sesión para permitir que los usuarios cierren sesión manualmente

Evite llamar automáticamente a la API de cierre de sesión

Obligatorio

(Muy) Recomendado

Seguir especificaciones obligatorias de encabezados

Reutilizar código de la API de REST v1

Implementar la administración de errores mejorada

Implementar la administración de errores HTTP

-