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

Cette page propose 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 est inaccessible

Si vous ne parvenez pas à atteindre un point de terminaison de l'API:

Valider vos identifiants d'API

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

  1. Dans Looker, accédez au panneau 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 l'écran vers le bas et 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 consulter l'ID client et cliquer sur l'icône représentant un œ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.

Valider l'URL de l'API

Un autre problème courant pour atteindre un point de terminaison d'API est une URL d'hôte d'API incorrecte. La plupart des instances Looker utilisent l'URL par défaut de l'API. Toutefois, les installations Looker utilisant un chemin d'API alternatif ou les installations Looker 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 et le port d'hôte de l'API.

Les administrateurs Looker peuvent consulter 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 Administration 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, soit:

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

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

  1. Ouvrez un navigateur et ouvrez la console du navigateur. Cet article du site ConcreteCMS.org peut vous être utile si vous avez besoin de savoir comment ouvrir une console pour votre navigateur.

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

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

    Si le champ API Host URL (URL de l'hôte de l'API) est vide, utilisez l'URL par défaut de l'API. Par exemple, pour les instances hébergées sur Google Cloud, Microsoft Azure et hébergées sur Amazon Web Services (AWS) créées le 07/07/2020 ou après, 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 créées avant le 07/07/2020, le chemin d'accès de 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, elle renvoie une page Web vierge, et non une page d'erreur.

Vous pouvez également vérifier que vous avez bien atteint l'API en consultant la réponse du réseau dans la console du 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 concernant la validation du transfert.

Vérifier le port de l'API

Si les vérifications ci-dessus échouent et que vous disposez d'un déploiement de Looker hébergé par le client, il est possible que le port d'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 le client, demandez à votre administrateur réseau de vérifier les paramètres de port de l'API. Le port d'API est le plus souvent 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 identiques pour le port d'API et pour votre port d'instance Looker:

  • Proxys
  • Load balancers
  • Pare-feu

Valider l'URL d'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 de l'hôte d'API par défaut, le format d'une URL de point de terminaison de l'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 dans l'APIs Explorer, sur le portail des développeurs de Looker 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 d'accès relatif suivant pour le point de terminaison "Toutes les requêtes en cours d'exécution" :

/api/4.0/running_queries

Par conséquent, l'URL du point de terminaison de l'API complète pour le point de terminaison Get All Running Query 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 de texte illisible, il est probable que le contenu binaire d'un fichier PDF, PNG ou JPG s'affiche. 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 REST HTTP gère la réponse de l'API comme des données binaires, et non comme du texte. Dans certains cas, cela peut impliquer la définition d'un indicateur dans l'appel d'API pour indiquer à la bibliothèque HTTP HTTP qu'il s'agit d'un résultat binaire, ou la gestion du résultat d'une manière spéciale (par exemple, comme un flux d'octets ou un 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 pouvez ouvrir l'explorateur d'API, mais que vos appels d'API ne répondent pas, vérifiez que le paramètre URL de l'hôte 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 la documentation Paramètres d'administration - API).

Erreurs d'encodage non valides

Si vous recevez une erreur d'encodage lorsque vous essayez 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 de protocole HTTP exigent que toutes les requêtes POST, PUT ou PATCH contiennent un en-tête Content-Type. Étant donné que l'API Looker utilise JSON de manière continue, l'en-tête Content-Type doit être défini sur application/json.

Notez que l'utilisation d'un SDK Looker gère automatiquement ce problème.

Erreurs de méthode introuvable

Si une erreur "Méthode introuvable" telle que method not found: all_looks() s'affiche, vérifiez d'abord la version de votre API. Plusieurs appels d'API nouveaux ou supprimés dans l'API 4.0 ont été supprimés. Consultez l'annonce concernant l'API Looker 4.0 en disponibilité générale 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 coupable est souvent un code JSON non valide ou non valide, peut-être une erreur d'analyse. Dans la plupart des cas, les erreurs 400 ont déjà passé l'authentification. Le message de réponse fournit donc des informations plus spécifiques sur l'erreur.

Erreurs 403 interdites

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'est pas autorisé. Le renvoi d'une erreur 403 au lieu d'une erreur 404 peut permettre, dans certains cas, de vérifier l'existence d'un objet Explorer, d'un tableau de bord ou d'un objet LookML spécifique lorsque le propriétaire préfère ne pas être connu. Pour éviter cela, Looker renvoie une erreur 404 et le message d'erreur suivant dans l'interface utilisateur de Looker: "Impossible de trouver la page demandée. Soit il n'existe pas, soit vous n'êtes pas autorisé à 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 à l'API peuvent être différents. Lorsque 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 API 443 par défaut, 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 le client, consultez la page Options de démarrage de Looker pour savoir comment définir le port d'API.

Cela peut également se produire lorsque vous utilisez une version obsolète du gem du SDK Ruby. Veillez à mettre à jour ces informations. Pour le vérifier, rendez-vous sur 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 "Introuvable" (404)

Une erreur 404 Not Found est l'erreur par défaut en cas de problème, généralement avec des autorisations. Le message de réponse d'une erreur 404 fournit un minimum d'informations, voire aucune. C'est intentionnel, car les erreurs 404 sont présentées aux personnes 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 servir à cartographier la "surface d'attaque" de l'API Looker.

Si des tentatives de connexion à l'API renvoient des erreurs 404, il est très probable que l'ID client ou le code secret du client API ne soit pas valide (voir Valider vos identifiants d'API plus haut sur cette page). Le point de terminaison REST de l'API est l'un des points de terminaison suivants, selon la version d'API utilisée:

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

Si vous utilisez une API de codegen Swagger ou un SDK Looker, assurez-vous que la valeur base_url est correcte:

  • Pour un client de codegen Swagger, base_url doit correspondre à l'un des éléments suivants, selon la version d'API utilisée :
    • https://<your-looker-hostname>:<port>/api/4.0/
    • https://<your-looker-hostname>:<port>/api/3.1/

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

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

Une erreur 404 peut également s'afficher une fois que vous êtes connecté. Si vous êtes connecté et qu'une erreur 404 s'affiche, cela signifie que vous n'êtes pas autorisé à utiliser 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 de code d'état 405. Le champ doit contenir la liste des méthodes actuellement compatibles avec la ressource cible.

Par exemple, vous pouvez rencontrer ce problème dans Looker : si vous avez essayé 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 possible via l'API Looker. Une erreur 405 se produit donc.

Erreurs (409) en conflit

Le code d'état de la 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 (autre que Looker) se produit lors de l'importation d'un fichier plus ancien que celui existant sur le serveur, ce qui entraîne un conflit de contrôle des versions.

Vous pouvez rencontrer cette erreur dans Looker lorsque vous essayez d'extraire une nouvelle branche Git à l'aide de l'API ou avec 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 a échoué aux vérifications des données. La requête comporte un ou plusieurs des types d'erreurs suivants (la réponse indiquera précisément les erreurs):

  • 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 son format est incorrect. Par exemple, si vous essayez de créer un aperçu 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 déjà présent dans votre instance Looker. Par exemple, les noms de connexion aux bases de données doivent être uniques. Si vous essayez de créer une connexion à une base de données utilisant le nom d'une connexion existante, vous obtenez 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 requis, ou sur les champs non valides. Le message de réponse affiche toutes les erreurs de validation en même temps. Par conséquent, si des champs sont manquants ou 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, mais la valeur db_timezone était incorrecte.

Erreurs de requête trop nombreuses (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 délai donné ("limitation du débit"). Pour en savoir plus sur les règles de limitation du débit de Looker, consultez l'article de la communauté Looker Le nombre de requêtes API que vous pouvez envoyer en même temps est-il limité ?

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 traiter la requête.

Cette réponse d'erreur est une réponse générique "catch-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 systématiquement lorsque vous essayez d'interagir avec Looker, nous vous recommandons de contacter l'assistance Looker.