View a markdown version of this page

Contrat de protocole HTTP - Amazon Bedrock AgentCore

Contrat de protocole HTTP

Découvrez les exigences relatives à la mise en œuvre du protocole HTTP dans votre application d'agent. Utilisez le protocole HTTP pour créer des points de terminaison d'API REST directs pour les request/response modèles traditionnels et des points de WebSocket terminaison pour les connexions de streaming bidirectionnelles en temps réel.

Note

Les points de terminaison HTTP (/invocations) et WebSocket (/ws) peuvent être déployés sur le même conteneur à l'aide du port 8080, ce qui permet d'implémenter un seul agent pour prendre en charge à la fois les interactions API traditionnelles et le streaming bidirectionnel en temps réel.

Pour un exemple de code, voir Commencer avec la AgentCore CLI.

Exigences relatives aux contenants

Votre agent doit être déployé sous la forme d'une application conteneurisée répondant aux spécifications suivantes :

  • Hôte : 0.0.0.0

  • Port : 8080 - Port standard pour la communication des HTTP-based agents

  • Plateforme : conteneur ARM64 - Nécessaire pour la compatibilité avec l' AgentCore environnement d'exécution

Exigences relatives au chemin

/invocations - POST

Il s'agit du point de terminaison principal de l'interaction avec l'agent avec entrée et JSON/SSE sortie JSON.

Objectif

Reçoit les demandes entrantes des utilisateurs ou des applications et les traite selon la logique métier de votre agent

Cas d’utilisation

Le /invocations point de terminaison répond à plusieurs objectifs clés :

  • Interactions et conversations directes avec les utilisateurs

  • Intégrations d'API avec des systèmes externes

  • Traitement par lots de plusieurs demandes

  • Real-time réponses en streaming pour les opérations de longue durée

Exemple de format de demande

Content-Type: application/json { "prompt": "What's the weather today?" }

Formats de réponse

Votre agent peut répondre en utilisant l'un des formats suivants selon le cas d'utilisation :

Réponse JSON (sans diffusion en continu)

Objectif

Fournit des réponses complètes aux demandes qui peuvent être traitées rapidement

Cas d’utilisation

Les réponses JSON sont idéales pour :

  • Scénarios simples de réponse aux questions

  • Calculs déterministes

  • Recherches rapides de données

  • Confirmations de statut

Exemple de format de réponse JSON

Content-Type: application/json { "response": "Your agent's response here", "status": "success" }

Réponse SSE (streaming)

Server-sent les événements (SSE) vous permettent de fournir des réponses en streaming en temps réel. Pour plus d'informations, consultez la spécification Server-sent des événements.

Objectif

Permet de fournir des réponses incrémentielles pour les opérations de longue durée et d'améliorer l'expérience utilisateur

Cas d’utilisation

Les réponses SSE sont idéales pour :

  • Real-time expériences conversationnelles

  • Génération de contenu progressive

  • Long-running calculs avec résultats intermédiaires

  • Flux de données en direct et mises à jour

Exemple de format de réponse SSE

Content-Type: text/event-stream data: {"event": "partial response 1"} data: {"event": "partial response 2"} data: {"event": "final response"}

/ws - WebSocket (Facultatif)

Il s'agit du point de WebSocket connexion principal pour les communications bidirectionnelles en temps réel.

Objectif

Accepte les demandes de WebSocket mise à niveau et maintient des connexions persistantes pour les interactions avec les agents de streaming

Cas d’utilisation

Le /ws point de terminaison répond à plusieurs objectifs clés :

  • Real-time interfaces conversationnelles

  • Sessions interactives pour les agents avec feedback immédiat

  • Traitement des données en streaming avec communication bidirectionnelle

Etablissement de la connexion

WebSocket les connexions commencent par une demande de mise à niveau HTTP :

Exemple de demande de mise à niveau HTTP

GET /ws HTTP/1.1 Host: agent-endpoint Connection: Upgrade Upgrade: websocket Sec-WebSocket-Version: 13 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== X-Amzn-Bedrock-AgentCore-Runtime-Session-Id: session-uuid

Exemple de réponse de WebSocket mise à niveau

HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Exigences relatives à la gestion des messages

Votre WebSocket point de terminaison doit gérer :

  • Acceptation de la connexion : appel await websocket.accept() pour établir la connexion

  • Réception de messages : Support des types de messages texte ou binaires en fonction des besoins de votre application

  • Traitement des messages : gérez les messages entrants conformément à la logique métier de votre agent

  • Envoi de réponses : envoyez les réponses appropriées en utilisant send_text() ou send_bytes()

  • Cycle de vie des connexions : gestion de l'établissement, de la maintenance et de la résiliation des connexions

Formats de message

Messages texte
Format JSON (recommandé)

Objectif

Échange de données structuré pour les interactions entre agents

Exemple de message

{ "prompt": "Hello, can you help me with this question?", "session_id": "session-uuid", "message_type": "user_message" }

Exemple de réponse

{ "response": "I'd be happy to help you with your question!", "session_id": "session-uuid", "message_type": "agent_response" }
Format de texte brut

Objectif

Communication simple basée sur du texte

Exemple

Hello, can you help me with this question?
Messages binaires

Objectif

Support pour les données non textuelles telles que les images, le son ou d'autres formats binaires

Cas d’utilisation

Les messages binaires prennent en charge plusieurs scénarios :

  • Multi-modal interactions entre les agents

  • Chargements et téléchargements de fichiers

  • Transmission de données compressées

  • Données du protocole binaire

Exigences relatives à la manipulation

La gestion des messages binaires nécessite :

  • Utilisation receive_bytes() et send_bytes() méthodes

  • Mettre en œuvre un traitement de données binaires approprié

  • Tenez compte des limites de taille des messages

Cycle de vie des connexions

Établissement de la connexion
  1. Handshake HTTP : le client envoie une demande de WebSocket mise à niveau

  2. Réponse de mise à niveau : l'agent accepte et renvoie 101 protocoles de commutation

  3. WebSocket Actif : début de la communication bidirectionnelle

  4. Liaison de session : associez la connexion à l'identifiant de session

Échange de messages
  1. Boucle continue : implémenter une boucle d'écoute des messages

  2. Traitement des messages : gestion des messages entrants de manière asynchrone

  3. Génération de réponses : envoyez les réponses appropriées

  4. Gestion des erreurs : gestion des exceptions et des problèmes de connexion

/ping - OBTENIR

Objectif

Vérifie que votre agent est opérationnel et prêt à traiter les demandes

Cas d’utilisation

Le /ping point de terminaison répond à plusieurs objectifs clés :

  • Surveillance des services pour détecter et résoudre les problèmes

  • Restauration automatisée grâce à AWS l'infrastructure gérée

Format de réponse

Renvoie un code de statut indiquant l'état de santé de votre agent :

  • Content-Type : application/json

  • Code d'état HTTP : 200 pour des codes d'erreur sains et appropriés pour des états non sains

Si votre agent doit traiter des tâches en arrière-plan, vous pouvez l'indiquer avec le /ping statut. Si l'état du ping est défini sur HealthyBusy cette valeur, la session d'exécution est considérée comme active.

Exemple de format de réponse Ping

{ "status": "<status_value>" }
statut (obligatoire)

Healthy- Le système est prêt à accepter de nouveaux travaux

HealthyBusy- Le système est opérationnel mais il est actuellement occupé par des tâches asynchrones. Tant que le statut est HealthyBusy défini, la session d'exécution est considérée comme active et est maintenue active.

time_of_last_update (facultatif)

Horodatage Unix (en secondes) de la date de dernière modification. status Réglez-le uniquement lors d'un changement de statut réel.

Avertissement

Ne réglez time_of_last_update pas l'heure actuelle à chaque ping. Un horodatage qui avance à chaque ping indique un changement d'état continu, ce qui empêche le délai d'inactivité de se déclencher. Les sessions persistent alors jusqu'à ce que votre quota de sessions soit épuisé MaxLifetime et peuvent être épuisées. Si vous omettez ce champ, la plateforme suit elle-même les changements de statut. Si vous utilisez le AgentCore SDK Bedrock, la réponse ping est gérée pour vous.

Réponses d'authentification OAuth

OAuth-configured les agents respectent les normes d'authentification RFC 6749 (OAuth 2.0). Lorsque l'authentification est absente, le service renvoie une réponse 401 Unauthorized avec un WWW-Authenticate en-tête (conformément à la RFC 7235), permettant aux clients de découvrir les points de terminaison du serveur d'autorisation via l'API. GetRuntimeProtectedResourceMetadata

401 Accès non autorisé

Renvoyé lorsque l'en-tête d'autorisation est manquant.

WWW-Authenticate En-tête inclus :

WWW-Authenticate: Bearer resource_metadata="https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{ESCAPED_ARN}/invocations/.well-known/oauth-protected-resource?qualifier={QUALIFIER}"
Note

SigV4-configured les agents renvoient le HTTP 403 avec une ACCESS_DENIED erreur et n'incluent pas les WWW-Authenticate en-têtes.