Dépannage de l'API Looker

Cette page contient des 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 à atteindre un point de terminaison de l'API:

Valider vos identifiants pour l'API

Si le point de terminaison de votre API Looker n'est pas accessible, vérifiez d'abord que vos identifiants pour l'API sont corrects. Pour afficher vos identifiants d'API:

  1. Dans Looker, accédez au panneau d'administration en sélectionnant l'option Admin dans le panneau de navigation de gauche.
  2. Dans le panneau de gauche de la page Administration, faites défiler la page vers le bas, puis cliquez sur Utilisateurs.
  3. Recherchez votre nom d'utilisateur dans la liste, puis cliquez dessus pour modifier votre page d'utilisateur.
  4. Cliquez sur Modifier les clés API. Vous pouvez voir l'ID client. Vous pouvez également 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 pour l'API correspondent à ceux que vous utilisez dans votre script.

Valider l'URL de l'API

Une URL d'hôte d'API incorrecte est un autre problème courant permettant d'atteindre un point de terminaison d'API. La plupart des instances Looker utilisent l'URL par défaut de l'API. Toutefois, les installations Looker utilisant un autre chemin d'accès d'API, les installations Looker situées derrière un équilibreur de charge (par exemple, une configuration de cluster) ou tout autre proxy, risquent de 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 visibles par l'utilisateur.

Les administrateurs Looker peuvent voir l'URL de l'hôte de l'API dans les paramètres d'administration de l'API (décrits plus en détail sur la page de documentation Paramètres d'administration – API). Pour afficher l'URL de l'hôte de l'API:

  1. Accédez au panneau Administration en sélectionnant l'option Admin dans le panneau de navigation de gauche.
  2. Cliquez sur API dans le panneau Administration.

  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, à savoir:

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

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

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

  2. Saisissez l'URL de l'hôte de l'API suivie de /alive. Par exemple, si votre URL d'hôte d'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 celles hébergées sur Amazon Web Services (AWS) créées à partir du 07/07/2020, le chemin d'accès à l'API Looker par défaut utilise le port 443:

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

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

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

Si l'URL de l'hôte de l'API est correcte, cette URL renverra une page Web vierge et non une page d'erreur.

Vous pouvez également vérifier si vous avez accédé à l'API en consultant 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 dû au fait que vous appelez l'API de manière incorrecte ou que votre code comporte d'autres erreurs. 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 du 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 API doive être ouvert sur l'infrastructure réseau.

Le port de l'API doit rediriger 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 d'API est généralement 443 ou 19999. Le port d'API doit avoir les mêmes paramètres de configuration que le port d'instance Looker (9999 par défaut). Votre administrateur réseau doit vérifier que les paramètres suivants sont les mêmes pour le port d'API et pour le port de votre instance Looker:

  • Proxys
  • Équilibreurs de charge
  • Pare-feu

Valider l'URL de l'appel d'API

Vérifiez que vous utilisez l'URL correcte 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 d'hôte de l'API par défaut, l'URL d'un point de terminaison d'API se présente comme suit:

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

Vous pouvez obtenir le format d'URL des points de terminaison de l'API dans APIs Explorer ou dans la documentation de référence de l'API.

Par exemple, la documentation de référence de l'API 4.0 donne le chemin relatif suivant pour le point de terminaison "Get All Running Query" (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 Query" (Obtenir toutes les requêtes en cours d'exécution) sur l'instance Looker docsexamples.dev.looker.com se présentera comme suit:

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 de texte illisible, il est probable que vous voyiez le contenu binaire d'un fichier PDF, PNG ou JPG. Certaines bibliothèques REST HTTP supposent que les réponses de l'API sont des fichiers texte, et que d'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 comme des données binaires, et non comme du texte. Dans certains cas, cela peut signifier définir un indicateur sur l'appel d'API pour indiquer à la bibliothèque REST HTTP qu'il s'agit d'un résultat binaire, ou traiter le résultat d'une manière spéciale, comme un flux d'octets ou un tableau d'octets, au lieu de l'attribuer à une variable de chaîne.

Les appels d'API ne répondent pas

Si vous pouvez ouvrir APIs Explorer, mais que vos appels d'API ne répondent pas, vérifiez que le paramètre API Host URL (URL de l'hôte de l'API) de votre instance Looker est correctement défini. Les administrateurs Looker peuvent voir l'URL de l'hôte de l'API dans les paramètres d'administration de l'API de 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 au cours de la requête. Les normes de 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 résoudra automatiquement ce problème.

Erreurs de méthode introuvable

Si vous obtenez une erreur de 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. Consultez l'annonce concernant la disponibilité générale de l'API Looker 4.0 pour obtenir la liste des mises à jour.

Erreurs de requête incorrecte (400)

Une erreur 400 Bad Request indique que les données fournies dans un appel d'API ne sont pas identifiables. Le problème provient souvent d'un fichier JSON non valide ou non valide, voire d'une erreur d'analyse. Dans la plupart des cas, les erreurs 400 ont déjà été authentifiées. Par conséquent, le message de réponse d'erreur fournira des informations plus spécifiques sur l'erreur.

Erreurs "Non autorisé (401)"

Une erreur 401 Unauthorized au niveau d'un appel d'API signifie que celui-ci n'est pas correctement authentifié. Pour en savoir plus sur la résolution des problèmes, consultez Comment résoudre les erreurs 401 ? Article de la communauté.

Erreurs "Interdit (403)"

L'API Looker ne renvoie pas d'erreurs 403 chaque fois qu'un utilisateur tente d'accéder à un objet LookML ou à un autre contenu pour lequel il n'a pas d'autorisation d'accès. Dans certains cas, le renvoi d'une erreur 403 au lieu d'une erreur 404 peut permettre de vérifier l'existence d'une exploration, d'un tableau de bord ou d'un objet LookML spécifique lorsque le propriétaire préférerait que cette information ne soit pas connue. Pour éviter cela, Looker renvoie une erreur 404 dans ces cas de figure et l'erreur associée dans l'interface utilisateur de Looker indique: "La page demandée est introuvable. Soit il n’existe pas, soit vous n’avez pas l’autorisation de le consulter. »

En fonction de l'environnement dans lequel votre instance Looker est hébergée et de sa configuration, le numéro de port et l'URL associée permettant d'accéder à l'API peuvent varier. Si vous utilisez un numéro de port incorrect, une erreur 403 peut s'afficher. 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 renvoie une erreur 403. Pour les instances hébergées par un client, vous pouvez en savoir plus sur les options de démarrage de Looker où vous pouvez définir le port d'API.

Cela peut également se produire lorsque vous utilisez une version obsolète du gem du SDK Ruby. N'oubliez pas de mettre régulièrement à jour ces gemmes. Vous pouvez vérifier à l'adresse https://rubygems.org/gems/looker-sdk.

Cela peut également se produire lorsque 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, une réponse 403 s'affiche.

Erreurs 404 (Page introuvable)

Une erreur 404 Not Found est l'erreur par défaut en cas de problème, généralement lié à des autorisations, par exemple. Le message de réponse à une erreur 404 fournit très peu d'informations, le cas échéant. Cette action est intentionnelle, car les erreurs 404 sont présentées aux utilisateurs disposant d'identifiants de connexion incorrects ou d'autorisations insuffisantes. 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 l'ID client ou le code secret du client pour l'API ne sont pas valides (voir Vérifier vos identifiants pour l'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 de génération de code Swagger ou un SDK Looker, assurez-vous que la valeur base_url est correcte:

  • Pour un client de génération de code Swagger, le base_url doit être le suivant:

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

  • Pour les implémentations de SDK Looker qui utilisent un looker.ini, la valeur de api_version doit être 4.0, et la valeur de base_url doit être identique à l'URL de votre API d'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>

Une erreur 404 peut également survenir après vous être connecté. 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 API que vous venez d'appeler.

Erreurs 405 (Méthode non autorisée)

Une erreur 405 Method Not Allowed indique que le serveur connaît la méthode de requête, mais que la ressource cible n'est pas compatible avec cette méthode.

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

Vous pouvez rencontrer ce problème dans Looker, par exemple, en essayant d'utiliser le point de terminaison update_dashboard() pour mettre à jour les métadonnées d'un tableau de bord LookML. L'API Looker ne permet pas de modifier le paramètre id d'un tableau de bord LookML. Par conséquent, une erreur 405 se produirait.

Erreurs de conflit (409)

Le code d'état de la réponse 409 Conflict indique un conflit de requêtes 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, autre que Looker, de cette erreur se produit lors du téléchargement d'un fichier plus ancien que celui existant sur le serveur, ce qui entraîne un conflit de contrôle des versions.

Cette erreur peut se produire 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)

Des erreurs de validation se produisent lorsqu'un élément de la requête n'a pas réussi lors de la vérification des données. La requête comporte un ou plusieurs des types d'erreurs suivants (la réponse d'erreur précise 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 à aucune 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 à aucune requête existante, vous obtiendrez une erreur de validation.
  • Existe déjà: l'appel d'API tente de créer un objet avec un ID ou un nom déjà présent 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 de base de données qui utilise le nom d'une connexion existante, vous obtiendrez une erreur de validation avec le code already_exists.

Consultez le message de réponse d'erreur pour en savoir plus sur les champs manquants ou obligatoires, ou ceux susceptibles de contenir des valeurs non valides. Le message de réponse fournira toutes les erreurs de validation en même temps. Ainsi, si des champs sont manquants et incorrects, la réponse d'erreur liste 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 avait également une valeur non valide dans db_timezone.

Erreurs "Trop de demandes (429)"

Le code d'état de la 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 Y a-t-il une limite au nombre de requêtes API que vous pouvez envoyer simultanément ?

Erreurs "Erreur interne du serveur" (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 traiter la requête.

Cette réponse d'erreur est une réponse générique (« fourch-all »). Cela indique généralement 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. Par conséquent, si cette erreur s'affiche régulièrement lorsque vous essayez d'interagir avec Looker, nous vous recommandons d'ouvrir une demande d'assistance.