Autorización
Todas las solicitudes a las APIs 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 el tipo de aplicación que estés escribiendo. El siguiente proceso general se aplica a todos los tipos de aplicación:
- Para prepararte para el proceso de autorización, haz lo siguiente:
- Registra tu aplicación con la Consola de API de Google.
- Activa las APIs de Fotos y recupera los detalles de OAuth, como un ID de cliente 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 le envía una solicitud a Google para obtener un ámbito de acceso en particular.
- Google muestra una pantalla de consentimiento al usuario en la que se le solicita que autorice a la aplicación a 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. Si deseas obtener información detallada sobre los flujos para varios tipos de aplicaciones, consulta Usa OAuth 2.0 para acceder a las APIs 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 en caché por más de 60 minutos según nuestros lineamientos de uso.
Tampoco debes almacenar baseUrls, que vencen después de aproximadamente 60 caracteres
minutos.
ID 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). Usa los IDs de elementos multimedia y de álbumes para recuperar las URLs y los 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 muchos elementos multimedia para actualizar, 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
HTTPS es obligatorio para todas las solicitudes de servicios web de las APIs de Fotos que usan el 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 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.
En el caso de los errores 429, el cliente puede reintentar 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 indicaciones.
Retirada exponencial
En raras ocasiones, puede producirse un error en 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 punto entre tu cliente y el servidor de Google. A menudo, vale la pena reintentar la
solicitud. La solicitud de seguimiento puede tener éxito cuando la original falló. 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. Por lo general, la demora aumenta conforme a un factor multiplicativo con cada intento; un enfoque conocido como retirada exponencial.
También debes tener la precaución de que no haya un código de reintento más alto en la cadena de llamada de la aplicación que provoque solicitudes repetidas en una sucesión rápida.
Uso correcto de las APIs de Google
Los clientes de API de diseño deficiente pueden presentar una mayor carga que la necesaria en Internet y en los servidores de Google. En esta sección, se explican algunas de las prácticas recomendadas para los 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
Grandes cantidades de solicitudes sincronizadas a las APIs de Google pueden percibirse como un ataque de denegación de servicio distribuido (DDoS) en la infraestructura de Google, y abordarse en consecuencia. Para evitar esto, debes asegurarte de que las solicitudes de API no se sincronicen entre clientes.
Por ejemplo, considera una aplicación que muestre la hora en la zona horaria actual. 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 llamadas a la API como parte del procesamiento asociado 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. Una aplicación mal diseñada que hace esto produce un pico de tráfico al inicio de cada minuto que equivale a sesenta veces los niveles normales.
En su lugar, 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 pantalla al inicio del minuto, la aplicación usa los resultados almacenados previamente 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, 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.