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 lo aprueba, Google le proporciona a la aplicación un token de acceso que vence después de un breve período.
- 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, mostrará los datos solicitados.
Para determinar qué permisos son adecuados para tu aplicación, consulta Permisos de autorización.
El proceso de algunos tipos de aplicaciones incluye pasos adicionales, como el uso de tokens 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 vence después de aproximadamente 60
minutos.
Los IDs de elementos multimedia y de álbumes que identifican de forma única 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 obtener más información, consulta Cómo obtener un elemento multimedia o Cómo enumerar á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
Se requiere HTTPS para todas las solicitudes de servicios web de la API de Photos 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 controlar los errores que muestra la API, consulta Cómo controlar errores en las APIs de Cloud.
Vuelve a intentar las solicitudes que fallaron
Los clientes deben reintentar en los errores 5xx con la retirada exponencial, como se describe en Retirada exponencial. El retraso mínimo debe ser 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 realizar varias solicitudes repetidas a los servidores de Google. Este comportamiento repetitivo puede sobrecargar la red entre tu cliente y Google, y causar problemas para varias 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 normal 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 que tu aplicación se bloquee debido a abusos accidentales 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. Es probable que esta aplicación configure una alarma en el sistema operativo del cliente que lo despierte al inicio del minuto, de modo que la hora que se muestra pueda actualizarse. 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 no es recomendable, ya que provoca que las llamadas a la API se sincronicen al inicio del minuto, incluso entre diferentes dispositivos, en lugar de distribuirse de forma pareja 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 de la sincronización al inicio del minuto, con otros momentos de sincronización comunes se debe tener la precaución de que no se produzcan al inicio de la hora y al inicio de cada día a la medianoche.