Soluciona problemas de la API de Looker

En esta página, se incluyen procedimientos para solucionar los siguientes problemas que puedes encontrar con la API de Looker:

No se puede acceder extremo de API

Si no puedes acceder a un extremo de API, haz lo siguiente:

Verifica tus credenciales de API

Si no se puede acceder a tu extremo de API de Looker, primero verifica que tus credenciales de la API sean correctas. Para ver tus credenciales de la API, sigue estos pasos:

  1. En Looker, selecciona la opción Administrador en el panel de navegación izquierdo para acceder al panel de administrador.
  2. En el panel izquierdo de la página Administrador, desplázate hacia abajo y haz clic en Usuarios.
  3. Busca tu nombre de usuario en la lista de usuarios y haz clic en él para editar tu página de usuario.
  4. Haz clic en Editar claves de API. Puedes ver el ID de cliente y hacer clic en el ícono del ojo para ver el secreto del cliente de cada clave de API que hayas configurado. Verifica que tus credenciales de la API coincidan con las que usas en tu secuencia de comandos.

Verifica la URL de la API

Otro problema común para acceder a un extremo de API es una URL de host de API incorrecta. La mayoría de las instancias de Looker usan la URL predeterminada para la API. Sin embargo, es posible que las instalaciones de Looker que usan una ruta de API alternativa o que se encuentran detrás de un balanceador de cargas (por ejemplo, una configuración de clúster) o cualquier otro proxy no usen la URL predeterminada. Si este es el caso, la URL del host de la API debe indicar el nombre de host y el puerto de la API orientada al usuario.

Los administradores de Looker pueden ver la URL del host de la API en la configuración de administrador de la API (que se describe con más detalle en la página de documentación Configuración de administrador: API). Para ver la URL del host de la API, haz lo siguiente:

  1. Haz clic en el ícono del menú principal de Looker y selecciona Administrador para abrir el panel Administrador.
  2. Haz clic en API en el panel Administrador.

  3. Consulta la URL del host de la API.

    Si el campo URL del host de la API está en blanco, tu instancia de Looker usará el formato predeterminado, que es el siguiente:

    https://<instance_name>.cloud.looker.com:<port>

Para probar la URL del host de la API, haz lo siguiente:

  1. Abre un navegador y, luego, abre la consola del navegador.

  2. Ingresa la URL del host de la API seguida de /alive. Por ejemplo, si la URL del host de la API es https://company.cloud.looker.com, ingresa lo siguiente:

    https://company.cloud.looker.com/alive

    Si el campo URL del host de la API está en blanco, usa la URL de la API predeterminada. Por ejemplo, para las instancias alojadas en Google Cloud, Microsoft Azure y las instancias alojadas en Amazon Web Services (AWS) que se crearon a partir del 7/7/2020, la ruta de acceso predeterminada de la API de Looker usa el puerto 443:

    https://<instance_name>.cloud.looker.com:443/alive

    En el caso de las instancias alojadas en AWS que se crearon antes del 7/7/2020, la ruta de acceso predeterminada de la API de Looker usa el puerto 19999:

    https://<instance_name>.cloud.looker.com:19999/alive

Si la URL del host de la API es correcta, esta URL generará una página web en blanco, no una página de error.

También puedes verificar que llegaste a la API observando la respuesta de la red en la consola del navegador. La respuesta de la red debe ser 200.

Si estas verificaciones fallan, es posible que estés llamando a la API de forma incorrecta o que tengas otros errores en tu código. Verifica las llamadas a la API y el código de tu secuencia de comandos. Si son correctos, consulta la siguiente sección para verificar tu puerto.

Verifica el puerto de la API

Si fallan las verificaciones anteriores y tienes una implementación de Looker alojada por el cliente, es posible que debas abrir el puerto de la API en la infraestructura de red.

El puerto de la API debe reenviarse al servidor de Looker. En el caso de las implementaciones de Looker alojadas por el cliente, pídele al administrador de red que verifique la configuración del puerto de la API. El puerto de la API suele ser 443 o 19999. El puerto de la API debe tener la misma configuración que el puerto de la instancia de Looker (9999 de forma predeterminada). El administrador de red debe verificar que la configuración que se indica a continuación sea la misma para el puerto de la API que para el puerto de la instancia de Looker:

  • Proxies
  • Balanceadores de cargas
  • Firewalls

Verifica la URL de la llamada a la API

Verifica que estés usando la URL correcta para la llamada a la API. El formato de la URL de un extremo de API es el siguiente:

<API Host URL>/api/<API version>/<API call>

Si usas la URL de host de API predeterminada, el formato de una URL de extremo de API es el siguiente:

https://<instance_name>:<port>/api/<API version>/<API call>

Puedes obtener el formato de URL para los extremos de la API desde el Explorador de API o desde la documentación de la Referencia de la API.

Por ejemplo, la Referencia de la API 4.0 proporciona la siguiente ruta relativa para el extremo Get All Running Queries:

/api/4.0/running_queries

Por lo tanto, la URL completa del extremo de API para el extremo Get All Running Queries en la instancia de Looker docsexamples.dev.looker.com sería la siguiente:

https://docsexamples.dev.looker.com:443/api/4.0/running_queries

El resultado de la API es texto sin sentido

Si la API devuelve una respuesta de texto ilegible, es probable que veas el contenido binario de un archivo PDF, PNG o JPG. Algunas bibliotecas de REST HTTP suponen que las respuestas de la API serán archivos de texto, por lo que otros tipos de archivos se muestran como texto binario.

En este caso, debes asegurarte de que tu biblioteca de REST HTTP controle la respuesta de la API como datos binarios, no como texto. En algunos casos, esto podría significar establecer una marca en la llamada a la API para indicarle a la biblioteca de REST de HTTP que es un resultado binario, o bien podría significar controlar el resultado de una manera especial, como un flujo de bytes o un array de bytes, en lugar de asignar el resultado a una variable de cadena.

Las llamadas a la API no responden

Si puedes abrir el Explorador de APIs, pero tus llamadas a la API no responden, verifica que el parámetro de configuración URL del host de la API de tu instancia de Looker esté configurado correctamente. Los administradores de Looker pueden ver la URL del host de la API en la configuración de administrador de la API de Looker (que se describe en la página de documentación Configuración de administrador: API).

Errores de codificación no válidos

Si recibes un error de codificación cuando intentas realizar una llamada a la API, es posible que debas establecer el Content-Type adecuado en el encabezado durante la solicitud. Los estándares del protocolo HTTP requieren que cualquier solicitud POST, PUT o PATCH contenga un encabezado Content-Type. Dado que la API de Looker usa JSON en todo momento, el encabezado Content-Type debe establecerse en application/json.

Ten en cuenta que el uso de un SDK de Looker controlará automáticamente este problema por ti.

Errores de método no encontrado

Si recibes un error de método no encontrado, como method not found: all_looks(), lo primero que debes verificar es la versión de la API. Hay varias llamadas a la API que son nuevas en la API 4.0 o que se quitaron en la API 4.0. Consulta el anuncio Disponibilidad general de la API de Looker 4.0 para ver la lista de actualizaciones.

Errores de solicitud incorrecta (400)

Un error 400 Bad Request indica que los datos proporcionados en una llamada a la API no se pueden reconocer. A menudo, el problema es un JSON roto o no válido, tal vez un error de análisis. En su mayor parte, los errores 400 ya pasaron la autenticación, por lo que el mensaje de respuesta de error proporcionará información más específica sobre el error.

Errores de autorización (401)

Un error 401 Unauthorized en una llamada a la API significa que la llamada a la API no se autenticó correctamente. Para obtener más detalles sobre la solución de problemas, consulta ¿Cómo soluciono los errores 401? Artículo de la comunidad.

Errores prohibidos (403)

La API de Looker no devuelve errores 403 cada vez que un usuario intenta acceder a un objeto de LookML o a otro contenido para el que no tiene permiso. En algunos casos, devolver un error 403 en lugar de un error 404 podría verificar la existencia de un Explorar, un panel o un objeto LookML en particular cuando el propietario prefiere que no se sepa. Para evitar esto, Looker devuelve un error 404 en estos casos, y el error correspondiente en la IU de Looker dice: "No se pudo encontrar la página que solicitaste. No existe o no tienes permiso para verla".

Según el entorno en el que se aloja tu instancia de Looker y la configuración de esta, el número de puerto y la URL asociada en la que se puede acceder a la API pueden ser diferentes. Cuando usas un número de puerto incorrecto, es posible que veas un error 403. Por ejemplo, si tu instancia de Looker está configurada con el puerto de API predeterminado 443, conectarse a https://mycompany.looker.com/api/4.0/login en lugar de https://mycompany.looker.com:443/api/4.0/login devolverá un error 403. En el caso de las instancias alojadas por el cliente, puedes obtener más información sobre las opciones de inicio de Looker, en las que puedes definir el puerto de la API.

Esto también puede suceder cuando usas una versión desactualizada de la gem del SDK de Ruby. Asegúrate de mantener actualizadas esas gemas. Puedes consultarlo en https://rubygems.org/gems/looker-sdk.

Esto también puede ocurrir cuando no incluyes la parte /api/<version number>/ de la URL. En este caso, si un usuario intenta conectarse a https://mycompany.looker.com:443/login, verá una respuesta 403.

Errores 404 (no se encontró la página)

Un error 404 Not Found es el error predeterminado si algo sale mal, por lo general, con aspectos como los permisos. El mensaje de respuesta para un error 404 proporciona información mínima, si es que proporciona alguna. Esto es intencional, ya que los errores 404 se muestran a las personas que tienen credenciales de acceso incorrectas o permisos insuficientes. Looker no quiere proporcionar información específica en los mensajes de respuesta 404, ya que esta información se podría usar para mapear la "superficie de ataque" de la API de Looker.

Si los intentos de acceso a la API muestran errores 404, es muy probable que tu ID de cliente o secreto del cliente de la API no sean válidos (consulta Verifica tus credenciales de la API más arriba en esta página). El extremo de REST de acceso a la API es el siguiente:

  • https://<your-looker-hostname>:<port>/api/4.0/login

Si usas una API de Swagger codegen o un SDK de Looker, asegúrate de que el valor de base_url sea correcto:

  • Para un cliente de codegen de Swagger, el base_url debe ser el siguiente:

    • https://<your-looker-hostname>:<port>/api/4.0/

  • En el caso de las implementaciones del SDK de Looker que usan un looker.ini, el valor de api_version debe ser 4.0, y el valor de base_url debe ser el mismo que la URL de la API de tu instancia de Looker en el formato https://<your-looker-hostname>:<port>. A continuación, se muestra un archivo looker.ini de ejemplo:

    # api_version should be 4.0
api_version=4.0
base_url=https://<your-looker-hostname>:<port>

También puedes recibir un error 404 después de acceder. Si accediste y recibes un error 404, significa que no tienes permisos para el comando de la API que acabas de llamar.

Errores de método no permitido (405)

Un error 405 Method Not Allowed indica que el servidor conoce el método de solicitud, pero el recurso de destino no lo admite.

El servidor debe generar un campo de encabezado Allow en una respuesta con el código de estado 405. El campo debe contener una lista de los métodos que admite el recurso de destino.

Por ejemplo, una forma en la que podrías encontrarte con esto en Looker sería si intentaras usar el extremo update_dashboard() para actualizar los metadatos de un panel de LookML. No se admite el cambio del parámetro id de un panel de LookML a través de la API de Looker, por lo que se produciría un error 405.

Errores de conflicto (409)

El código de estado de respuesta 409 Conflict indica un conflicto de solicitud con el estado actual del recurso de destino.

Es más probable que se produzcan conflictos en respuesta a una solicitud PUT. Un ejemplo común de este error que no es de Looker ocurre cuando se sube un archivo que es más antiguo que el existente en el servidor, lo que genera un conflicto de control de versión.

Es posible que encuentres este error en Looker cuando intentes extraer una nueva rama de Git con la API o cuando uses extremos como create_group() o create_dashboard(). En estos casos, verifica si el objeto que intentas crear ya existe.

Errores de validación (422)

Los errores de validación se producen cuando algo en la solicitud no pasó las verificaciones de datos realizadas. La solicitud tiene uno o más de los siguientes tipos de errores (la respuesta de error especificará los errores exactos):

  • Faltan campos: No se proporcionó un parámetro obligatorio (la respuesta de error indicará qué campo falta).
  • No válido: El valor proporcionado no coincide con un valor existente o no tiene el formato correcto. Por ejemplo, si intentas crear un Look y el ID de consulta que proporcionas en la llamada a la API no coincide con una consulta existente, recibirás un error de validación.
  • Ya existe: La llamada a la API intenta crear un objeto con un ID o un nombre que ya está presente en tu instancia de Looker. Por ejemplo, los nombres de las conexiones de bases de datos deben ser únicos. Si intentas crear una conexión de base de datos nueva que use el nombre de una conexión existente, recibirás un error de validación con el código already_exists.

Consulta el mensaje de respuesta de error para obtener detalles sobre los campos que pueden haber faltado o que eran obligatorios, o bien los campos que pueden tener valores no válidos. El mensaje de respuesta proporcionará todos los errores de validación al mismo tiempo. Por lo tanto, si faltan campos y también hay campos incorrectos, la respuesta de error enumerará todos los problemas con la llamada a la API.

Esta es una respuesta de ejemplo:

{
  "message": "Validation Failed",
  "errors": [
    {
    "field": "dialect",
    "code": "missing_field",
    "message": "This field is required.",
    "documentation_url": "http://docs.looker.com/"
    },
    {
    "field": "db_timezone",
    "code": "invalid",
    "message": "Must specify a database timezone when user timezones are activated.",
    "documentation_url": "http://docs.looker.com/"
    }
  ],
    ...

En este caso, la llamada a la API no incluía el campo obligatorio dialect y también tenía un valor no válido en el campo db_timezone.

Errores de Demasiadas solicitudes (429)

El código de estado de respuesta 429 Too Many Requests indica que el usuario envió demasiadas solicitudes en un período determinado ("límite de frecuencia"). Puedes leer más sobre las políticas de límite de frecuencia de Looker en la publicación de Comunidad de Looker Is there a limit to the number of API requests you can send at one time? (¿Existe un límite para la cantidad de solicitudes a la API que puedes enviar al mismo tiempo?).

Errores internos del servidor (500)

El código de respuesta 500 Internal Server Error indica que el servidor encontró una condición inesperada que le impidió completar la solicitud.

Esta respuesta de error es una respuesta genérica de "captura todo". Por lo general, esto indica que el servidor no puede encontrar un código de error 5xx más específico para devolver en la respuesta. Cualquier respuesta 500 de Looker es inesperada, por lo que, si ves este error de forma constante cuando intentas interactuar con Looker, te recomendamos que abras una solicitud de asistencia.