Résoudre les problèmes d’utilisation du générateur d’API de données pour les bases de données Azure

Article
07/30/2024

Cet article fournit des solutions aux erreurs courantes qui peuvent se produire lorsque vous utilisez le générateur d’API de données pour les bases de données Azure.

Point de terminaison générique : erreur HTTP 400 « Demande incorrecte »

Les sections suivantes décrivent les causes et solutions à l’erreur HTTP 400 « Demande incorrecte ».

Point de terminaison du générateur d’API de données non valide

La base du composant de chemin d’URL est mappée au point de terminaison REST ou GraphQL du générateur d’API de données. Lorsque la base du composant de chemin d’URL ne correspond pas à la valeur définie dans la configuration du runtime du générateur d’API de données, le générateur d’API de données retourne une erreur HTTP 400 « Requête incorrecte ».

Vous pouvez configurer les chemins d’accès racine pour les points de terminaison GraphQL et REST dans la runtime section de la configuration du runtime du générateur d’API de données. Vous devez utiliser les valeurs pour commencer les chemins d’URL des points de terminaison REST et GraphQL.

Par exemple, la configuration suivante définit /api comme chemin racine du point de terminaison REST et /graphql comme racine du point de terminaison GraphQL :

"runtime": {
    "rest": {
      "enabled": true,
      "path": "/api"
    },
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "...": "...",
}

Par conséquent, les valeurs que vous devez utiliser au début des chemins d’URL pour les points de terminaison REST et GraphQL sont les suivantes :

/api/<entity>

/graphql

Note

Lorsque vous utilisez le générateur d’API de données avec Static Web Apps à l’aide de la fonctionnalité Connexions de base de données, le chemin d’URL commence par /data-api. Vous pouvez ajouter la valeur de votre point de terminaison souhaité après cette valeur. Par exemple, /data-api/api/<entity> pour REST et /data-api/graphql pour GraphQL.

Problème de configuration des connexions de base de données Static Web Apps

Lorsque vous utilisez le générateur d’API de données avec la fonctionnalité Connexions de base de données Static Web Apps, vous rencontrez l’erreur « Le code d’état de la réponse n’indique pas la réussite : 400 (Demande incorrecte) » dans le corps de la réponse :

{"Message":"{\u0022Message\u0022:\u0022Response status code does not indicate success: 400 (Bad Request).\u0022,\u0022ActivityId\u0022:\u0022<GUID>\u0022}","ActivityId":"<GUID>"}

Cette erreur peut indiquer un problème avec la configuration que vous avez fournie lors de la liaison de votre base de données.

Pour résoudre ce problème, effectuez les étapes suivantes :

Vérifiez que vos informations d’identification de base de données sont valides dans un outil tel qu’Azure Data Studio ou SQL Server Management Studio (SSMS).
Dissocier/dissocier la base de données connectée.

Si vous rencontrez toujours l’erreur, veillez à sélectionner Autoriser les services et ressources Azure à accéder à ce serveur pour les exceptions sur la page réseau de votre ressource Azure Database. Cette option configure le pare-feu pour autoriser les connexions à partir d’adresses IP allouées à n’importe quel service ou ressource Azure, y compris les connexions provenant d’abonnements d’autres clients.

Point de terminaison REST : Erreur HTTP 404 « Introuvable »

Si l’URL demandée pointe vers un itinéraire qui n’est associé à aucune entité, une erreur HTTP 404 est retournée. Par défaut, le nom de l’entité est également le nom de l’itinéraire. Par exemple, si vous configurez l’exemple d’entité Todo dans le fichier de configuration comme dans l’exemple suivant :

"Todo": {
      "source": "dbo.todos",
      "...": "..."
    }

Ensuite, l’entité Todo est accessible via l’itinéraire suivant :

/<rest-route>/Todo

Si vous spécifiez la propriété dans la rest.path configuration todode l’entité, comme illustré dans l’exemple suivant :

"Todo": {
    "source": "dbo.todos",
    "rest": {
      "path": "todo"
    },
    "...": "..."
  }

Ensuite, l’itinéraire d’URL de l’entité Todo est todo, avec tous les caractères minuscules correspondant à la valeur exacte définie dans la configuration du runtime :

/<rest-route>/todo

Point de terminaison GraphQL : Erreur HTTP 400 « Demande incorrecte »

Une requête GraphQL génère une erreur HTTP 400 « Requête incorrecte » chaque fois que la requête GraphQL est construite de manière incorrecte. Cela peut être dû à un champ d’entité non existant ou à un nom d’entité mal orthographié. Le générateur d’API de données retourne une erreur descriptive et des détails d’erreur dans la charge utile de réponse.

Lorsque vous envoyez une GET requête au point de terminaison GraphQL, le corps de réponse de l’erreur retournée indique « La requête de paramètre ou l’ID de paramètre doit être défini ». Veillez à envoyer vos requêtes GraphQL à l’aide de HTTP POST.

Point de terminaison GraphQL : Erreur HTTP 404 « Introuvable »

Vérifiez que la requête GraphQL est envoyée au point de terminaison GraphQL configuré à l’aide de la méthode HTTP POST . Par défaut, l’itinéraire du point de terminaison GraphQL est /graphql.

Point de terminaison GraphQL : « La requête du type d’objet doit au moins définir un champ afin d’être valide »

Lorsque le démarrage du générateur d’API de données ne parvient pas à générer un schéma GraphQL en fonction de votre configuration d’exécution, vous recevez le message d’erreur :

La requête de type objet doit au moins définir un champ pour être valide.

La spécification GraphQL nécessite au moins qu’un Query objet soit défini dans le schéma GraphQL. Vous devez vérifier que votre configuration d’exécution répond à l’une des conditions suivantes :

L’action read est définie pour au moins une entité GraphQL. GraphQL est activé sur les entités par défaut. Vérifiez donc que vous n’appliquez pas cette atténuation à une entité configurée avec {"graphql": false}.
Lorsque vous exposez uniquement des procédures stockées, définissez { "graphql": { "operation": query" } } sur au moins une entité de procédure stockée, qui remplace le type mutationd’opération GraphQL de procédure stockée par défaut.

Vous devez disposer d’au moins une procédure stockée qui lit uniquement et ne modifie pas les données. Sinon, la génération de schéma GraphQL échoue en raison d’un champ vide query dans le schéma.

Point de terminaison GraphQL : l’introspection ne fonctionne pas avec le point de terminaison GraphQL

Les outils qui prennent en charge GraphQL utilisent normalement l’introspection de schéma GraphQL sans nécessiter de configuration supplémentaire. Veillez à définir la propriété allow-introspection true de configuration du runtime dans la runtime.graphql section de configuration. Par exemple :

"runtime": {
    "...": "...",
    "graphql": {
      "allow-introspection": true,
      "enabled": true,
      "path": "/graphql"
    },
    "...": "..."
}

Point de terminaison GraphQL : « L’opération <de mutation operation_name> a réussi, mais l’utilisateur actuel n’est pas autorisé à afficher la réponse en raison d’un manque d’autorisations de lecture »

Pour qu’une opération de mutation GraphQL reçoive une réponse valide, les autorisations de lecture doivent être configurées en plus du type d’opération de mutation respectif : créer, mettre à jour et supprimer. Comme l’indique l’erreur, l’opération de mutation (création/mise à jour/suppression) a réussi au niveau de la couche de base de données, mais l’absence d’autorisation de lecture a provoqué le retour d’un message d’erreur par le générateur d’API de données. Par conséquent, veillez à configurer les autorisations de lecture dans le rôle « Anonyme » ou le rôle avec lequel vous souhaitez exécuter l’opération de mutation.

Erreur générale : erreur HTTP 500 retournée par les requêtes

Les erreurs HTTP 500 indiquent que le générateur d’API de données ne peut pas fonctionner correctement sur la base de données back-end. Vérifiez que les conditions suivantes sont respectées :

Le générateur d’API de données peut toujours se connecter à la base de données configurée.
Les objets de base de données utilisés par le générateur d’API de données sont toujours disponibles et accessibles.

Pour permettre au générateur d’API de données de retourner des erreurs de base de données spécifiques dans les réponses, définissez la runtime.host.mode propriété de configuration sur development:

"runtime": {
    [...]
    "host": {
        "mode": "development",
        [...]
    }
}

Par défaut, le générateur d’API de données s’exécute avec runtime.host.mode la valeur productiondéfinie sur . En production mode, le générateur d’API de données ne retourne pas d’erreurs détaillées dans la charge utile de réponse.

Dans les deux development modes, production le générateur d’API de données écrit des erreurs détaillées dans la console pour faciliter la résolution des problèmes.

Erreurs générales en raison de demandes non authentifiées et non autorisées

Erreur HTTP 401 « Non autorisé »

Les erreurs HTTP 401 se produisent lorsque le point de terminaison et l’entité accessibles nécessitent l’authentification et que le demandeur ne fournit pas de métadonnées d’authentification valides dans leur requête.

Lorsque vous configurez le générateur d’API de données pour utiliser l’authentification Microsoft Entra ID, vos requêtes entraînent des erreurs HTTP 401 lorsque le jeton du porteur fourni (accès) n’est pas valide. Un jeton d’accès peut être non valide pour de nombreuses raisons. En voici quelques-unes :

Le jeton d’accès a expiré.
Le jeton d’accès n’est pas destiné à l’API du générateur d’API de données (audience de jeton d’accès incorrecte).
Le jeton d’accès n’est pas créé par l’autorité attendue (émetteur de jeton d’accès non valide).

Pour résoudre cette erreur, veillez à respecter les conditions suivantes :

Vous générez un jeton d’accès à l’aide de la issuer valeur définie dans la authentication section de la configuration du runtime.
Votre jeton d’accès est généré pour la audience valeur définie dans la authentication section de la configuration du runtime.

Voici un exemple de configuration :

"authentication": {
    "provider": "AzureAD",
    "jwt": {
        "issuer": "https://login.microsoftonline.com/24c24d79-9790-4a32-bbb4-a5a5c3ffedd5/v2.0/",
        "audience": "b455fa3c-15fa-4864-8bcd-88fd83d686f3"
    }
}

Vous devez générer un jeton valide pour l’audience définie. Lorsque vous utilisez Azure CLI, vous pouvez obtenir un jeton d’accès en spécifiant l’audience dans le resource paramètre :

az account get-access-token --resource "b455fa3c-15fa-4864-8bcd-88fd83d686f3"

Erreur HTTP 403 « Interdit »

Si vous envoyez une requête authentifiée à l’aide de l’intégration Static Web Apps ou de l’ID Microsoft Entra, vous pouvez recevoir une erreur HTTP 403 « Interdit ». Cette erreur indique que vous essayez d’utiliser un rôle qui n’existe pas dans le fichier de configuration.

Cette erreur se produit quand :

Vous ne fournissez pas d’en-tête X-MS-API-ROLE HTTP spécifiant un nom de rôle.

Étant donné que les requêtes authentifiées sont exécutées dans le contexte du rôle authenticated système par défaut, ce scénario s’applique uniquement lorsque vous utilisez un rôle non système (pas authenticated ni ).anonymous
Le rôle que vous définissez dans l’en-tête X-MS-API-ROLE n’est pas configuré dans le fichier de configuration runtime du générateur d’API de données.
Le rôle que vous définissez dans l’en-tête X-MS-API-ROLE ne correspond pas au rôle dans votre jeton d’accès.

Par exemple, dans le fichier de configuration d’exécution suivant, le rôle role1 est défini. Vous devez donc fournir un X-MS-API-ROLE en-tête HTTP avec la valeur role1.

Note

La mise en correspondance des noms de rôles respecte la casse.

"Todo": {
    "role": "role1",
    "actions": [ "*" ]
}

References

Étape suivante

Si votre problème n’est pas résolu, fournissez des commentaires ou signalez-le dans les discussions data-api-builder.

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.

Partager via