API unsupport the channel
Causes
Le schéma HTTP de la requête est invalide.
Chaque API prend en charge un schéma HTTP spécifique. Les fournisseurs d'API peuvent configurer une API pour qu'elle accepte uniquement le protocole HTTP, uniquement le protocole HTTPS, ou les deux.
API unsupport the channel : une requête HTTP a été envoyée à une API qui ne prend en charge que le protocole HTTPS.
API unsupport the channel : une requête HTTPS a été envoyée à une API qui ne prend en charge que le protocole HTTP.
Solutions
API unsupport the channel : utilisez le protocole HTTPS au lieu du protocole HTTP pour appeler l'API.
API unsupport the channel : utilisez le protocole HTTP au lieu du protocole HTTPS pour appeler l'API.
A403IS
Causes
La signature fournie par le client ne correspond pas à la signature générée côté serveur.
Solutions
En cas de non-correspondance des signatures, API Gateway renvoie la chaîne StringToSign calculée côté serveur dans l'en-tête de réponse X-Ca-Error-Message.
StringToSign contient la chaîne utilisée pour calculer la signature avant l'envoi de la requête. Pour plus d'informations, consultez la rubrique Utiliser l'authentification par résumé pour appeler une API.
Comparez votre chaîne StringToSign locale avec celle renvoyée dans la réponse. Si vous avez utilisé la démo officielle, récupérez la chaîne StringToSign depuis la classe d'outil de calcul de signature.
Les en-têtes de réponse HTTP ne prenant pas en charge les sauts de ligne, ces derniers sont supprimés de la réponse dans la chaîne StringToSign. Tenez compte de cette différence lors de la comparaison des chaînes.
Si les chaînes côté client et côté serveur correspondent, vérifiez la validité des valeurs AppKey et AppSecret. Assurez-vous notamment qu'elles ne contiennent pas d'espaces supplémentaires.
Invalid Url
Causes
La méthode HTTP, le chemin d'accès ou l'environnement (X-Ca-Stage) spécifié dans la requête est invalide.
Par exemple, la requête cible une API dans l'environnement de test, mais cette API n'a pas été publiée dans cet environnement.
Note:
Si vous ne spécifiez aucun environnement dans votre requête, celle-ci est envoyée par défaut à l'environnement de production (RELEASE).
Si vous modifiez la définition d'une API, vous devez la republier pour que les modifications prennent effet. Cette erreur survient fréquemment lorsque le chemin d'accès de l'API est modifié sans republication de l'API.
Solutions
Vérifiez les trois éléments suivants dans votre requête : la méthode HTTP, le chemin d'accès et l'environnement.
Utilisez la même méthode HTTP que celle définie pour l'API. Par exemple, si une API nécessite une méthode POST, n'envoyez pas de requête GET.
Utilisez le chemin d'accès correct. Si vous êtes propriétaire de l'API, republiez-la après toute modification.
Spécifiez l'environnement dans lequel vous souhaitez appeler l'API. Utilisez l'en-tête X-Ca-Stage dans votre requête. Les valeurs valides sont TEST, PRE et RELEASE, qui indiquent respectivement l'environnement de test, l'environnement de préproduction et l'environnement de production. Si vous ne spécifiez pas cet en-tête, votre requête est envoyée par défaut à l'environnement de production.
Unauthorized
Causes
L'application n'est pas autorisée à appeler l'API.
Solution
Essayez les solutions suivantes :
Si vous avez créé l'API, créez une application dans la console API Gateway et autorisez-la à appeler l'API. Une application est requise même pour tester votre propre API.
Si vous avez acheté l'API, consultez la page des détails de l'application pour voir la liste des API autorisées. Si l'API cible ne figure pas dans la liste, demandez une autorisation.
Si l'API appartient à un partenaire, contactez ce dernier pour obtenir l'autorisation. Fournissez votre ID d'application (AppId) afin que le partenaire puisse autoriser votre application.
Les autorisations sont spécifiques à chaque environnement. Une application autorisée dans un environnement ne peut pas appeler la même API dans un autre environnement.
Vérifiez que vous utilisez la bonne combinaison d'application et d'API. Les incompatibilités sont fréquentes lorsque vous gérez plusieurs applications ou API.
I403AA
Causes
L'application appelante ne dispose pas des permissions d'accès nécessaires pour appeler l'API cible, ce qui entraîne l'échec de la vérification d'autorisation.
API Gateway renvoie le code d'état HTTP 403. L'en-tête de réponse X-Ca-Error-Code est défini sur I403AA et l'en-tête de réponse X-Ca-Error-Message est défini sur Invalid App Authorization no permission.
Solution
Dans la console API Gateway, vérifiez si l'application appelante dispose des permissions d'accès nécessaires pour appeler l'API cible. Si l'autorisation est manquante, autorisez l'application appelante dans la console ou appelez SetApisAuthorities pour accorder les permissions d'accès requises. Envoyez ensuite à nouveau la requête.