Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résoudre les problèmes liés au streaming des réponses dans API Gateway
Les conseils de dépannage suivants peuvent vous aider à résoudre les problèmes liés à APIs l'utilisation du streaming de réponses.
Résolution de problème généraux
Vous pouvez utiliser l'onglet de test TestInvokeMethodou l'onglet de test de la console pour tester la réponse de votre stream. Les considérations suivantes peuvent avoir un impact sur votre utilisation de test invoke pour le streaming des réponses :
-
Lorsque vous testez votre méthode, API Gateway met en mémoire tampon votre charge utile de réponse diffusée en continu. Une fois que l'une des conditions suivantes est remplie, API Gateway renvoie une réponse unique contenant la charge utile mise en mémoire tampon :
La demande est complète
35 secondes se sont écoulées
Plus de 1 Mo de charge utile de réponse ont été mis en mémoire tampon
-
Si plus de 35 secondes s'écoulent avant que votre méthode ne renvoie un statut de réponse HTTP et tous les en-têtes, le statut de réponse renvoyé est 0. TestInvokeMethod
-
API Gateway ne produit aucun journal d'exécution.
Après avoir déployé votre API, vous pouvez tester la réponse de votre flux à l'aide d'une commande curl. Nous vous recommandons d'utiliser l'-ioption permettant d'inclure les en-têtes de réponse du protocole dans la sortie. Pour voir les données de réponse telles qu'elles arrivent, utilisez l'option curl --no-buffer
Résoudre les erreurs cURL
Si vous testez une intégration et que vous recevez le message d'erreurcurl: (18) transfer closed with outstanding
read data remaining, assurez-vous que le délai d'expiration de votre intégration est suffisamment long. Si vous utilisez une fonction Lambda, vous devez mettre à jour le délai de réponse de la fonction Lambda. Pour plus d'informations, voir Configurer le délai d'expiration de la fonction Lambda.
Résoudre les problèmes liés à la journalisation des accès
Vous pouvez utiliser les journaux d'accès pour votre stage d'API REST afin de consigner et de dépanner votre flux de réponses. Outre les variables existantes, vous pouvez utiliser les variables du journal d'accès suivantes :
$context.integration.responseTransferMode-
Le mode de transfert des réponses de votre intégration. Il peut correspondre à
BUFFEREDouSTREAMED. $context.integration.timeToAllHeadersLe délai entre le moment où API Gateway établit la connexion d'intégration et le moment où il reçoit tous les en-têtes de réponse d'intégration du client.
$context.integration.timeToFirstContentLe délai entre le moment où API Gateway établit la connexion d'intégration et le moment où il reçoit les premiers octets de contenu.
$context.integration.latencyou$context.integrationLatencyL'heure à laquelle API Gateway établit la connexion d'intégration jusqu'à ce que le flux de réponse d'intégration soit terminé.
La figure suivante montre comment ces variables du journal d'accès représentent les différents composants d'un flux de réponses.
Pour plus d’informations sur les journaux d’accès, consultez Configuration de la CloudWatch journalisation pour REST APIs dans API Gateway. Vous pouvez également utiliser X-Ray pour surveiller votre flux de réponses. Pour de plus amples informations, veuillez consulter Suivi des demandes des utilisateurs adressées aux API REST à l’aide de X-Ray dans API Gateway.
