Résoudre les problèmes liés à l'API Looker

Cette page décrit les procédures de dépannage pour les problèmes suivants que vous pouvez rencontrer avec l'API Looker :

Le point de terminaison de l'API n'est pas accessible

Si vous ne parvenez pas à accéder à un point de terminaison d'API :

Valider vos identifiants API

Si votre point de terminaison de l'API Looker n'est pas accessible, commencez par vérifier que vos identifiants d'API sont corrects. Pour afficher vos identifiants API :

  1. Dans Looker, accédez au panneau "Admin" en sélectionnant l'option Admin dans le panneau de navigation de gauche.
  2. Dans le panneau de gauche de la page Admin, faites défiler la page vers le bas, puis cliquez sur Utilisateurs.
  3. Recherchez votre nom d'utilisateur dans la liste des utilisateurs, puis cliquez dessus pour modifier votre page utilisateur.
  4. Cliquez sur Modifier les clés API. Vous pouvez voir l'ID client et cliquer sur l'icône en forme d'œil pour afficher le code secret du client pour chaque clé API que vous avez configurée. Vérifiez que vos identifiants d'API correspondent à ceux que vous utilisez dans votre script.

Vérifier l'URL de l'API

Un autre problème courant pour accéder à un point de terminaison d'API est une URL hôte d'API incorrecte. La plupart des instances Looker utilisent l'URL par défaut pour l'API. Toutefois, les installations Looker qui utilisent un autre chemin d'API ou qui sont situées derrière un équilibreur de charge (par exemple, une configuration de cluster) ou tout autre proxy peuvent ne pas utiliser l'URL par défaut. Dans ce cas, l'URL de l'hôte de l'API doit indiquer le nom d'hôte et le port de l'API destinés aux utilisateurs.

Les administrateurs Looker peuvent consulter l'URL de l'hôte de l'API dans les paramètres d'administration de l'API (pour en savoir plus, consultez la page de documentation Paramètres d'administration – API). Pour afficher l'URL de l'hôte de l'API :

  1. Cliquez sur l'icône Menu principal Looker , puis sélectionnez Admin pour ouvrir le panneau Admin.
  2. Cliquez sur API dans le panneau Admin.

  3. Affichez l'URL de l'hôte de l'API.

    Si le champ URL de l'hôte de l'API est vide, votre instance Looker utilise le format par défaut suivant :

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

Pour tester l'URL de l'hôte de l'API :

  1. Ouvrez un navigateur, puis la console du navigateur.

  2. Saisissez l'URL de l'hôte de l'API, suivie de /alive. Par exemple, si votre URL de l'hôte de l'API est https://company.cloud.looker.com, saisissez :

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

    Si le champ URL de l'hôte de l'API est vide, utilisez l'URL de l'API par défaut. Par exemple, pour les instances hébergées sur Google Cloud, Microsoft Azure et les instances hébergées sur Amazon Web Services (AWS) créées le 07/07/2020 ou après, le chemin d'accès par défaut à l'API Looker utilise le port 443 :

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

    Pour les instances hébergées sur AWS et créées avant le 07/07/2020, le chemin d'accès par défaut à l'API Looker utilise le port 19999 :

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

Si l'URL hôte de l'API est correcte, cette URL générera une page Web vide, et non une page d'erreur.

Vous pouvez également vérifier que vous avez atteint l'API en examinant la réponse du réseau dans la console de votre navigateur. La réponse du réseau doit être 200.

Si ces vérifications échouent, le problème peut être lié à un appel incorrect de l'API ou à d'autres erreurs dans votre code. Vérifiez vos appels d'API et le code de votre script. Si ces informations sont correctes, consultez la section suivante sur la vérification de votre port.

Vérifier le port de l'API

Si les vérifications précédentes échouent et que vous disposez d'un déploiement Looker hébergé par le client, il est possible que le port de l'API doive être ouvert sur l'infrastructure réseau.

Le port de l'API doit être transféré vers le serveur Looker. Pour les déploiements Looker hébergés par un client, demandez à votre administrateur réseau de vérifier les paramètres du port de l'API. Le port de l'API est généralement 443 ou 19999. Le port de l'API doit avoir les mêmes paramètres de configuration que le port de l'instance Looker (9999 par défaut). Votre administrateur réseau doit vérifier que les paramètres suivants sont identiques pour le port de l'API et pour le port de votre instance Looker :

  • les proxys ;
  • Équilibreurs de charge
  • Pare-feu

Vérifier l'URL de l'appel d'API

Vérifiez que vous utilisez la bonne URL pour votre appel d'API. Le format d'une URL de point de terminaison d'API est le suivant :

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

Si vous utilisez l'URL hôte de l'API par défaut, le format d'une URL de point de terminaison d'API est le suivant :

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

Vous pouvez obtenir le format d'URL des points de terminaison de l'API à partir de l'explorateur d'API ou de la documentation de référence de l'API.

Par exemple, la documentation de référence sur l'API 4.0 fournit le chemin d'accès relatif suivant pour le point de terminaison "Get All Running Queries" (Obtenir toutes les requêtes en cours d'exécution) :

/api/4.0/running_queries

Par conséquent, l'URL complète du point de terminaison de l'API pour le point de terminaison "Get All Running Queries" (Obtenir toutes les requêtes en cours d'exécution) sur l'instance Looker docsexamples.dev.looker.com serait la suivante :

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

Le résultat de l'API est un texte incompréhensible

Si l'API renvoie une réponse sous forme de texte illisible, il s'agit probablement du contenu binaire d'un fichier PDF, PNG ou JPG. Certaines bibliothèques HTTP REST supposent que les réponses de l'API seront des fichiers texte. Les autres types de fichiers sont donc affichés sous forme de texte binaire.

Dans ce cas, vous devez vous assurer que votre bibliothèque HTTP REST gère la réponse de l'API en tant que données binaires, et non en tant que texte. Dans certains cas, cela peut signifier définir un indicateur sur l'appel d'API pour indiquer à la bibliothèque HTTP REST qu'il s'agit d'un résultat binaire, ou cela peut signifier gérer le résultat d'une manière spéciale, par exemple sous forme de flux d'octets ou de tableau d'octets, au lieu d'attribuer le résultat à une variable de chaîne.

Les appels d'API ne répondent pas

Si vous parvenez à ouvrir l'explorateur d'API, mais que vos appels d'API ne répondent pas, vérifiez que le paramètre URL hôte de l'API de votre instance Looker est correctement défini. Les administrateurs Looker peuvent consulter l'URL de l'hôte de l'API dans les paramètres d'administration de l'API Looker (décrits sur la page de documentation Paramètres d'administration – API).

Erreurs d'encodage non valides

Si vous recevez une erreur d'encodage lorsque vous tentez d'effectuer un appel d'API, vous devrez peut-être définir le Content-Type approprié dans votre en-tête lors de la requête. Les normes du protocole HTTP exigent que toute requête POST, PUT ou PATCH contienne un en-tête Content-Type. Étant donné que l'API Looker utilise JSON partout, l'en-tête Content-Type doit être défini sur application/json.

Notez que l'utilisation d'un SDK Looker gérera automatiquement ce problème pour vous.

Erreurs "Méthode introuvable"

Si vous obtenez une erreur "Méthode introuvable", telle que method not found: all_looks(), la première chose à vérifier est la version de votre API. Plusieurs appels d'API sont nouveaux dans l'API 4.0 ou ont été supprimés dans l'API 4.0. Pour obtenir la liste des nouveautés, consultez l'annonce Disponibilité générale de l'API Looker 4.0.

Erreurs "Requête incorrecte (400)"

Une erreur 400 Bad Request indique que les données fournies dans un appel d'API sont méconnaissables. Le problème est souvent lié à un code JSON non fonctionnel ou non valide, peut-être une erreur d'analyse. La plupart du temps, les erreurs 400 ont déjà passé l'authentification. Le message de réponse d'erreur fournit donc des informations plus spécifiques sur l'erreur.

Erreurs 401 (Non autorisé)

Une erreur 401 Unauthorized lors d'un appel d'API signifie que l'appel d'API n'est pas correctement authentifié. Pour en savoir plus sur le dépannage, consultez Comment résoudre les erreurs 401 ? Article de la communauté.

Erreurs "Accès interdit" (403)

L'API Looker ne renvoie pas d'erreur 403 chaque fois qu'un utilisateur tente d'accéder à un objet LookML ou à un autre contenu pour lequel il n'a pas l'autorisation. Le renvoi d'une erreur 403 au lieu d'une erreur 404 peut, dans certains cas, confirmer l'existence d'un objet Explorer, d'un tableau de bord ou d'un objet LookML spécifique, alors que le propriétaire préférerait que cela ne soit pas connu. Pour éviter cela, Looker renvoie un code 404 dans ces cas, et l'erreur correspondante dans l'UI Looker indique : "La page que vous avez demandée est introuvable. Soit il n'existe pas, soit vous ne disposez pas des autorisations nécessaires pour le consulter."

En fonction de l'environnement dans lequel votre instance Looker est hébergée et de la configuration de votre instance Looker, le numéro de port et l'URL associée à partir desquels l'API est accessible peuvent être différents. Si vous utilisez un numéro de port incorrect, il est possible que l'erreur 403 s'affiche. Par exemple, si votre instance Looker est configurée avec le port d'API par défaut 443, la connexion à https://mycompany.looker.com/api/4.0/login au lieu de https://mycompany.looker.com:443/api/4.0/login renverra une erreur 403. Pour les instances hébergées par le client, vous pouvez en savoir plus sur les options de démarrage de Looker, qui vous permettent de définir le port de l'API.

Cela peut également se produire si vous utilisez une version obsolète du gem Ruby SDK. Veillez à les tenir à jour. Vous pouvez consulter https://rubygems.org/gems/looker-sdk.

Cela peut également se produire si vous n'incluez pas la partie /api/<version number>/ de l'URL. Dans ce cas, si un utilisateur tente de se connecter à https://mycompany.looker.com:443/login, il recevra une réponse 403.

Erreurs "Introuvable (404)"

L'erreur 404 Not Found est l'erreur par défaut en cas de problème, généralement lié aux autorisations. Le message de réponse pour une erreur 404 fournit peu d'informations, voire aucune. C'est normal, car les erreurs 404 s'affichent pour les personnes dont les identifiants de connexion sont incorrects ou qui ne disposent pas des autorisations suffisantes. Looker ne souhaite pas fournir d'informations spécifiques dans les messages de réponse 404, car ces informations pourraient être utilisées pour cartographier la surface d'attaque de l'API Looker.

Si les tentatives de connexion à l'API renvoient des erreurs 404, c'est probablement parce que votre ID client ou votre code secret du client de l'API ne sont pas valides (consultez Vérifier vos identifiants API plus haut sur cette page). Le point de terminaison REST de connexion à l'API est le suivant :

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

Si vous utilisez une API Swagger Codegen ou un SDK Looker, assurez-vous que votre valeur base_url est correcte :

  • Pour un client Swagger Codegen, le base_url doit être le suivant :

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

  • Pour les implémentations du SDK Looker qui utilisent un looker.ini, la valeur de api_version doit être 4.0 et la valeur de base_url doit être la même que l'URL de l'API de votre instance Looker au format https://<your-looker-hostname>:<port>. Voici un exemple de fichier looker.ini :

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

Il est également possible qu'une erreur 404 s'affiche après votre connexion. Si vous êtes connecté et que vous obtenez une erreur 404, cela signifie que vous ne disposez pas des autorisations nécessaires pour la commande d'API que vous venez d'appeler.

Erreurs "Méthode non autorisée (405)"

Une erreur 405 Method Not Allowed indique que le serveur connaît la méthode de requête, mais que la ressource cible ne la prend pas en charge.

Le serveur doit générer un champ d'en-tête Allow dans une réponse avec le code d'état 405. Le champ doit contenir une liste des méthodes compatibles avec la ressource cible.

Par exemple, vous pouvez rencontrer ce problème dans Looker si vous essayez d'utiliser le point de terminaison update_dashboard() pour mettre à jour les métadonnées d'un tableau de bord LookML. La modification du paramètre id d'un tableau de bord LookML n'est pas prise en charge par l'API Looker. Une erreur 405 se produirait donc.

Erreurs de conflit (409)

Le code d'état de réponse 409 Conflict indique un conflit de requête avec l'état actuel de la ressource cible.

Les conflits sont plus susceptibles de se produire en réponse à une requête PUT. Un exemple courant de cette erreur en dehors de Looker se produit lorsque vous importez un fichier plus ancien que celui qui existe déjà sur le serveur, ce qui entraîne un conflit de gestion des versions.

Vous pouvez rencontrer cette erreur dans Looker lorsque vous essayez d'extraire une nouvelle branche Git à l'aide de l'API ou lorsque vous utilisez des points de terminaison tels que create_group() ou create_dashboard(). Dans ce cas, vérifiez si l'objet que vous essayez de créer existe déjà.

Erreurs de validation (422)

Les erreurs de validation se produisent lorsqu'un élément de la requête échoue aux vérifications des données effectuées. La requête présente un ou plusieurs des types d'erreurs suivants (la réponse d'erreur indiquera les erreurs exactes) :

  • Champs manquants : un paramètre obligatoire n'a pas été fourni (la réponse d'erreur indique le champ manquant).
  • Non valide : la valeur fournie ne correspond pas à une valeur existante ou n'est pas au bon format. Par exemple, si vous essayez de créer un Look et que l'ID de requête que vous fournissez dans l'appel d'API ne correspond pas à une requête existante, une erreur de validation s'affiche.
  • Existe déjà : l'appel d'API tente de créer un objet avec un ID ou un nom qui existe déjà dans votre instance Looker. Par exemple, les noms de connexion à la base de données doivent être uniques. Si vous essayez de créer une connexion à une base de données en utilisant le nom d'une connexion existante, une erreur de validation s'affiche avec le code already_exists.

Consultez le message de réponse d'erreur pour savoir quels champs sont manquants ou obligatoires, ou quels champs comportent des valeurs non valides. Le message de réponse fournit toutes les erreurs de validation en même temps. Ainsi, si des champs sont manquants et d'autres incorrects, la réponse d'erreur listera tous les problèmes liés à votre appel d'API.

Voici un exemple de réponse :

{
  "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/"
    }
  ],
    ...

Dans ce cas, l'appel d'API ne comportait pas le champ obligatoire dialect et une valeur non valide avait été indiquée dans db_timezone.

Erreurs "Too Many Requests" (429)

Le code d'état de réponse 429 Too Many Requests indique que l'utilisateur a envoyé trop de requêtes dans un laps de temps donné ("limitation du débit"). Pour en savoir plus sur les règles de limitation du débit de Looker, consultez le post de la communauté Looker Is there a limit to the number of API requests you can send at one time? (Existe-t-il une limite au nombre de requêtes API que vous pouvez envoyer en même temps ?).

Erreurs de serveur interne (500)

Le code de réponse 500 Internal Server Error indique que le serveur a rencontré une condition inattendue qui l'a empêché de répondre à la requête.

Cette réponse d'erreur est une réponse générique "catch-all". En règle générale, cela indique que le serveur ne trouve pas de code d'erreur 5xx plus spécifique à renvoyer en réponse. Toute réponse 500 de Looker est inattendue. Si cette erreur s'affiche régulièrement lorsque vous essayez d'interagir avec Looker, nous vous recommandons d'envoyer une demande d'assistance.