Ir al contenido

Google

Las APIs de Google son interfaces de programación que permiten a una aplicación comunicarse con servicios y datos de Google mediante solicitudes definidas. En lugar de reproducir funciones como mapas, almacenamiento de archivos, análisis de tráfico o gestión del correo, una aplicación puede utilizar servicios como Google Maps Platform, Google Drive API, YouTube Data API, Google Analytics Data API o Gmail API.

Una API establece un contrato: indica qué operaciones están disponibles, qué datos debe enviar el cliente y qué respuesta recibirá. Muchas APIs Google exponen recursos mediante HTTP y siguen un estilo REST. Un recurso representa una entidad del servicio, como un vídeo, un archivo o un mensaje. Las respuestas suelen utilizar JSON, un formato de texto estructurado que las aplicaciones pueden interpretar con facilidad.

Para consumir una API normalmente se necesita un proyecto de Google Cloud, habilitar el servicio correspondiente y crear credenciales. El tipo de credencial depende de los datos y de la operación:

  • Una clave de API identifica el proyecto y se utiliza en operaciones que no requieren acceder a datos privados de un usuario.
  • OAuth 2.0 solicita el consentimiento del usuario y entrega un token de acceso limitado por permisos o scopes.
  • Una cuenta de servicio representa a una aplicación o carga de trabajo, no a una persona. Se utiliza sobre todo en procesos de servidor y en recursos a los que se le haya concedido acceso.

Autenticación y autorización no son equivalentes. La autenticación identifica quién realiza la solicitud; la autorización determina qué acciones puede ejecutar sobre cada recurso.

  • Catálogo especializado. Cada API ofrece recursos y operaciones propios. Maps trabaja con mapas, rutas y lugares; Drive con archivos y carpetas; Gmail con mensajes y etiquetas; YouTube con vídeos, canales y listas de reproducción; Analytics con métricas y dimensiones.
  • Acceso mediante endpoints. Un endpoint es una URL que representa una operación o un recurso. La aplicación combina esa URL con un método HTTP, parámetros, cabeceras y, cuando corresponde, un cuerpo de solicitud.
  • Respuestas estructuradas. La mayoría de las APIs web devuelve JSON. Los campos solicitados, la paginación y los filtros permiten reducir el volumen de datos transferido.
  • Credenciales según el contexto. Una clave de API puede bastar para ciertos datos públicos, mientras que los datos privados de Drive o Gmail requieren OAuth 2.0. Las cuentas de servicio son adecuadas para integraciones de servidor, pero no sustituyen automáticamente el consentimiento de un usuario.
  • Permisos granulares. Los scopes delimitan el acceso solicitado, por ejemplo, consultar archivos sin modificarlos. Conviene elegir el permiso mínimo necesario para reducir riesgos y simplificar la revisión de seguridad.
  • Cuotas y límites. Los proyectos disponen de cuotas por operación, usuario o periodo. Algunas plataformas también requieren una cuenta de facturación. La aplicación debe controlar errores de límite, evitar solicitudes innecesarias y aplicar reintentos con espera progresiva cuando la documentación lo recomiende.
  • Bibliotecas cliente y descubrimiento. Google publica bibliotecas para varios lenguajes que gestionan autenticación, serialización y llamadas HTTP. También es posible invocar directamente la API REST cuando se necesita una integración ligera o no existe una biblioteca adecuada.
  • Versionado independiente. Cada servicio evoluciona con su propia versión y política de cambios. La versión forma parte con frecuencia de la URL, como v3, por lo que hay que consultar la documentación específica de la API utilizada.

Conocer estas APIs permite integrar servicios existentes sin desarrollar toda su infraestructura. Una aplicación puede mostrar una ruta con Maps, subir documentos a Drive, consultar datos de Analytics, administrar vídeos de YouTube o automatizar tareas autorizadas de Gmail.

También ayuda a resolver aspectos comunes de una integración real:

  • Elegir entre una clave de API, OAuth 2.0 y una cuenta de servicio.
  • Diseñar un flujo de consentimiento que solicite solo los permisos necesarios.
  • Interpretar respuestas JSON y códigos de estado HTTP.
  • Recorrer resultados paginados mediante tokens de página.
  • Gestionar cuotas, errores transitorios y credenciales de forma segura.
  • Evitar exponer claves en repositorios, aplicaciones cliente o registros.

Estos conocimientos son transferibles a otras APIs web porque se apoyan en conceptos habituales: HTTP, REST, recursos, tokens, paginación y control de errores. La diferencia práctica está en conocer el modelo de datos, los permisos y las cuotas de cada servicio Google.

El siguiente ejemplo consulta vídeos públicos con YouTube Data API v3. Antes de ejecutarlo hay que crear un proyecto en Google Cloud, habilitar YouTube Data API v3 y generar una clave de API con restricciones apropiadas.

Ventana de terminal
curl --get 'https://www.googleapis.com/youtube/v3/search' \
--data-urlencode 'part=snippet' \
--data-urlencode 'q=apis google' \
--data-urlencode 'type=video' \
--data-urlencode 'maxResults=5' \
--data-urlencode 'key=TU_API_KEY'

La solicitud utiliza el endpoint search y envía estos parámetros:

  • part=snippet solicita los datos descriptivos de cada resultado.
  • q=apis google define el texto de búsqueda.
  • type=video excluye canales y listas de reproducción.
  • maxResults=5 limita la respuesta a cinco elementos.
  • key identifica el proyecto que consume la cuota.

La respuesta es un documento JSON. Cada elemento de items contiene un objeto id, con el identificador del vídeo, y un objeto snippet, con campos como title, description, channelTitle y publishedAt. Si existen más resultados, la respuesta puede incluir nextPageToken; ese valor se envía después como pageToken para solicitar la página siguiente.

La clave no debe quedar escrita directamente en código que se publique. En un script real conviene leerla desde una variable de entorno y restringirla en Google Cloud por API y, cuando sea posible, por origen, dirección IP o aplicación. Para acceder a información privada o ejecutar operaciones en nombre de un usuario, este ejemplo tendría que sustituir la clave por un token OAuth 2.0 con los permisos adecuados.

Artículos en Google

Puedes consultar todos los artículos de Google que tenemos en Línea de Código.