Autorización
Todas las solicitudes a la API de la Biblioteca de Google Fotos deben contar con la autorización de un usuario autenticado.
Los detalles del proceso de autorización para OAuth 2.0 varían un poco según el tipo de aplicación que escribas. El siguiente proceso general se aplica a todos los tipos de aplicación:
- Haz lo siguiente para prepararte para el proceso de autorización:
- Registra tu aplicación con la Consola de API de Google.
- Activa la API de Biblioteca y recupera los detalles de OAuth, como un ID y un secreto del cliente. Para obtener más información, consulta Cómo comenzar.
- Para acceder a los datos del usuario, la aplicación envía una solicitud a Google de un permiso de acceso específico.
- Google muestra una pantalla de consentimiento al usuario, en la que se le solicita que autorice a la aplicación para solicitar algunos de sus datos.
- Si el usuario la aprueba, Google le proporciona a la aplicación un token de acceso que vence después de un período breve.
- La aplicación realiza una solicitud para los datos del usuario y adjunta el token de acceso a la solicitud.
- Si Google determina que la solicitud y el token son válidos, mostrará los datos solicitados.
A fin de determinar qué alcances son adecuados para tu aplicación, consulta Alcances de autorización.
El proceso para algunos tipos de aplicación incluye pasos adicionales, como el uso de tokens de actualización para adquirir tokens de acceso nuevos. Si deseas obtener información detallada sobre los flujos para varios tipos de aplicaciones, consulta Usa OAuth 2.0 para acceder a las API de Google.
Almacenamiento en caché
Mantén los datos actualizados.
Si necesitas almacenar contenido multimedia (como miniaturas, fotos o videos) de forma temporal por motivos de rendimiento, no lo almacenes durante más de 60 minutos según nuestros lineamientos de uso.
Tampoco debes almacenar baseUrls, que vencen después de unos 60 minutos.
Los ID de elementos multimedia y los ID de álbumes que identifican contenido de manera inequívoca en la biblioteca de un usuario están exentos de la restricción de almacenamiento en caché. Puedes almacenar estos IDs de forma indefinida (sujeto a la política de privacidad de tu aplicación). Usa los ID de elementos multimedia y los ID de álbumes para volver a recuperar URL y datos accesibles mediante los extremos adecuados. Para obtener más información, consulta Cómo obtener un elemento multimedia o Cómo crear una lista de álbumes.
Si tienes que actualizar muchos elementos multimedia, podría ser más eficiente almacenar los parámetros de búsqueda que mostraron los elementos multimedia y volver a enviar la consulta para volver a cargar los datos.
Acceso SSL
Se requiere HTTPS para todas las solicitudes de servicio web de la API de la biblioteca que usen la siguiente URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Se rechazan las solicitudes realizadas a través de HTTP.
Manejo de errores
Para obtener información sobre cómo manejar los errores que muestra la API, consulta la sección sobre cómo manejar los errores para las APIs de Cloud.
Cómo reintentar solicitudes fallidas
Los clientes deben volver a intentarlo en los errores 5xx con retirada exponencial, como se describe en Retirada exponencial. El retraso mínimo debe ser de 1 s, a menos que se documente lo contrario.
Para errores 429, el cliente puede volver a intentarlo con un retraso mínimo de 30s. Para todos los demás errores, es posible que el reintento no sea aplicable. Asegúrate de que tu solicitud sea idempotente y consulta el mensaje de error para obtener orientación.
Retirada exponencial
En casos excepcionales, es posible que algo salga mal en la entrega de tu solicitud.Es posible que recibas un código de respuesta HTTP 4XX o 5XX, o que la conexión TCP falle en algún lugar entre tu cliente y el servidor de Google. A menudo, vale la pena volver a realizar la solicitud. La solicitud de seguimiento puede completarse con éxito cuando la original falló. Sin embargo, es importante no realizar bucles y realizar solicitudes repetidas a los servidores de Google. Este comportamiento en bucle puede sobrecargar la red entre tu cliente y Google y causar problemas a muchas partes.
Un mejor enfoque consiste en realizar nuevos intentos con demoras más prolongadas entre uno y otro. Por lo general, el retraso aumenta de acuerdo con un factor multiplicativo con cada intento, un enfoque conocido como retirada exponencial.
También debes tener cuidado de que no haya un código de reintento más alto en la cadena de llamadas de la aplicación que genere solicitudes repetidas en una sucesión rápida.
Uso formal de las APIs de Google
Los clientes de API mal diseñados pueden colocar más carga de la necesaria tanto en Internet como en los servidores de Google. En esta sección, se incluyen algunas prácticas recomendadas para los clientes de las APIs. Seguir estas prácticas recomendadas puede ayudarte a evitar que se bloquee tu aplicación por abuso involuntario de las APIs.
Solicitudes sincronizadas
Un gran número de solicitudes sincronizadas a las APIs de Google pueden parecer un ataque de denegación de servicio distribuido (DDoS) en la infraestructura de Google y se pueden tratar según corresponda. Para evitar que esto suceda, debes asegurarte de que las solicitudes a la API no estén sincronizadas entre clientes.
Por ejemplo, considera una aplicación que muestra la hora en la zona horaria actual. Es probable que esta aplicación establezca una alarma en el sistema operativo del cliente que lo despierte al comienzo del minuto para que se pueda actualizar la hora que se muestra. La aplicación no debe realizar ninguna llamada a la API como parte del procesamiento asociado con esa alarma.
Hacer llamadas a la API en respuesta a una alarma fija no es un problema, ya que hace que las llamadas a la API se sincronicen al comienzo del minuto, incluso entre diferentes dispositivos, en lugar de distribuirse de manera uniforme con el tiempo. Una aplicación mal diseñada que hace esto produce un aumento repentino de tráfico a sesenta veces los niveles normales al comienzo de cada minuto.
En cambio, un posible buen diseño es tener una segunda alarma configurada en una hora elegida al azar. Cuando se activa esta segunda alarma, la aplicación realiza llamadas a las APIs que necesita y almacena los resultados. Para actualizar la visualización al comienzo del minuto, la aplicación usa los resultados almacenados con anterioridad en lugar de volver a llamar a la API. Mediante este enfoque, las llamadas de API se distribuyen de forma equitativa con el tiempo. Además, las llamadas a la API no retrasan la renderización cuando se actualiza la pantalla.
Además del inicio del minuto, los demás momentos de sincronización comunes que debes tener en cuenta son los que se producen al inicio de una hora y al inicio de cada día a la medianoche.