Autorización
Todas las solicitudes a la API de la Biblioteca de Google Fotos deben estar autorizadas por un usuario autenticado.
Los detalles del proceso de autorización para OAuth 2.0 varían ligeramente según según el tipo de aplicación que escribas. El siguiente proceso general se aplica a todos los tipos de aplicaciones:
- Prepárate para el proceso de autorización de la siguiente manera:
- Registra tu aplicación con el Consola de APIs de Google.
- Activa la API de la Biblioteca y recupera los detalles de OAuth, como ID de cliente y un secreto de cliente. Para obtener más información, consulta Comienza ahora.
- Para acceder a los datos del usuario, la aplicación le solicita a Google un un permiso de acceso específico.
- Google le mostrará una pantalla de consentimiento al usuario, en la que se le pedirá que autorice la para solicitar algunos de sus datos.
- Si el usuario la aprueba, Google proporciona a la aplicación un token de acceso. que vence después de un período breve.
- La aplicación realiza una solicitud de 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, muestra el los datos solicitados.
Para determinar qué alcances son adecuados para tu aplicación, consulta Autorización permisos.
El proceso para algunos tipos de aplicación incluye pasos adicionales, como el uso de de actualización para adquirir nuevos tokens de acceso. Para obtener información detallada sobre para varios tipos de aplicaciones, consulta Uso de OAuth 2.0 para acceder APIs.
Almacenamiento en caché
Mantén los datos actualizados.
Si necesitas almacenar contenido multimedia temporalmente (como miniaturas, fotos o videos) Por razones de rendimiento, no lo almacenes durante más de 60 minutos según nuestro uso lineamientos.
Tampoco debes almacenar baseUrls, que vencen después de aproximadamente 60 caracteres
minutos.
IDs de elementos multimedia y de álbumes que identifican de manera inequívoca el contenido de 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). Cómo usar los ID de elementos multimedia y los ID de álbumes para recuperar URL y datos accesibles nuevamente con los extremos adecuados. Para para obtener más información, consulta Cómo obtener un archivo item o fichas álbumes.
Si tienes que actualizar muchos elementos multimedia, puede que sea más eficiente almacenar parámetros de búsqueda que mostraron los elementos multimedia y volver a enviar la consulta para volver a cargar de datos no estructurados.
Acceso SSL
Se requiere HTTPS para todas las solicitudes de servicios web a través de la API de Library con el siguiente URL:
https://photoslibrary.googleapis.com/v1/service/output?parameters
Las solicitudes realizadas a través de HTTP se rechazan.
Manejo de errores
Para obtener información sobre cómo manejar los errores que muestra la API, consulta Cloud Manejo de APIs errores.
Reintentar solicitudes fallidas
Los clientes deben reintentar los errores 5xx con la retirada exponencial como se describe en
Retirada exponencial. La demora mínima debe ser de 1 s
a menos que se documente lo contrario.
Si se producen 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, puede ocurrir un problema al entregar tu solicitud.Es posible que recibas un
Código de respuesta HTTP 4XX o 5XX, o la conexión TCP puede fallar en algún lugar
entre tu cliente y el servidor de Google. A menudo, vale la pena volver a intentarlo
para cada solicitud. La solicitud de seguimiento puede completarse correctamente si falla la original. Sin embargo,
es importante no repetir indefinidamente solicitudes
a los servidores de Google de forma reiterada. Esta
de 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. Generalmente, la demora aumenta por un factor multiplicativo con cada intento, un enfoque conocido como Exponencial retirada.
También debes tener cuidado de que no haya un código de reintento más alto en la aplicación. que lleva a solicitudes repetidas en sucesión rápida.
Uso correcto de las APIs de Google
Los clientes de API mal diseñados pueden cargar más carga de la necesaria tanto en en Internet y en los servidores de Google. Esta sección contiene algunas prácticas recomendadas clientes de las APIs. Seguir estas prácticas recomendadas puede ayudarte a evitar tu el bloqueo de la aplicación por uso involuntario de las APIs.
Solicitudes sincronizadas
Una gran cantidad de solicitudes sincronizadas a las APIs de Google puede verse como una ataque de denegación de servicio distribuido (Distributed Denial of Service, DDoS) en la infraestructura de Google, y se tratan como corresponde. Para evitar esto, debes asegurarte de que las solicitudes a la API se no se sincroniza entre clientes.
Por ejemplo, considera una aplicación que muestra la hora en la hora actual zona. Esta aplicación probablemente configurará una alarma en el sistema operativo del cliente activándolo al inicio del minuto para que la hora que se muestra pueda se actualicen. La aplicación no debe realizar ninguna llamada a la API como parte del procesamiento asociada con esa alarma.
Realizar llamadas a la API en respuesta a una alarma fija es malo porque da como resultado la de llamadas a la API sincronizadas al inicio del minuto, incluso entre diferentes en lugar de distribuirse de manera uniforme con el tiempo. Un diseño deficiente que hace esto produce un aumento repentino de tráfico a un nivel sesenta veces mayor que los normales. al comienzo de cada minuto.
Un buen diseño es tener una segunda alarma configurada en una alarma aleatoria la hora elegida. Cuando se activa esta segunda alarma, la aplicación realiza llamadas a cualquier las APIs que necesita y almacena los resultados. Para actualizar la pantalla al comienzo de la minuto, la aplicación usa resultados previamente almacenados en lugar de llamar al API de nuevo. 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, existen otros tiempos de sincronización comunes que debe tener cuidado de no orientar son al inicio de una hora y al inicio de todos los días a medianoche.