Réponse

Le bloc Réponse formate et envoie des réponses HTTP structurées aux appelants de l'API. Utilisez-le pour renvoyer les résultats du workflow avec les codes d'état et les en-têtes appropriés.

Configuration du bloc Réponse

Les blocs Réponse sont des blocs terminaux - ils mettent fin à l'exécution du workflow et ne peuvent pas se connecter à d'autres blocs.

Options de configuration

Données de réponse

Les données de réponse constituent le contenu principal qui sera renvoyé à l'appelant de l'API. Elles doivent être formatées en JSON et peuvent inclure :

  • Des valeurs statiques
  • Des références dynamiques aux variables du workflow en utilisant la syntaxe <variable.name>
  • Des objets et tableaux imbriqués
  • Toute structure JSON valide

Code d'état

Définissez le code d'état HTTP pour la réponse (par défaut 200) :

Succès (2xx) :

  • 200 : OK - Réponse de succès standard
  • 201 : Created - Ressource créée avec succès
  • 204 : No Content - Succès sans corps de réponse

Erreur client (4xx) :

  • 400 : Bad Request - Paramètres de requête invalides
  • 401 : Unauthorized - Authentification requise
  • 404 : Not Found - La ressource n'existe pas
  • 422 : Unprocessable Entity - Erreurs de validation

Erreur serveur (5xx) :

  • 500 : Internal Server Error - Erreur côté serveur
  • 502 : Bad Gateway - Erreur de service externe
  • 503 : Service Unavailable - Service temporairement indisponible

En-têtes de réponse

Configurez des en-têtes HTTP supplémentaires à inclure dans la réponse.

Les en-têtes sont configurés sous forme de paires clé-valeur :

CléValeur
Content-Typeapplication/json
Cache-Controlno-cache
X-API-Version1.0

Exemples de cas d'utilisation

Réponse d'endpoint API - Renvoyer des données structurées depuis une API de recherche

Agent (Search) → Function (Format & Paginate) → Response (200, JSON)

Confirmation de webhook - Accuser réception et traitement d'un webhook

Webhook Trigger → Function (Process) → Response (200, Confirmation)

Gestion des réponses d'erreur - Renvoyer des réponses d'erreur appropriées

Condition (Error Detected) → Router → Response (400/500, Error Details)

Sorties

Les blocs de réponse sont terminaux - ils mettent fin à l'exécution du workflow et envoient la réponse HTTP à l'appelant de l'API. Aucune sortie n'est disponible pour les blocs en aval.

Références de variables

Utilisez la syntaxe <variable.name> pour insérer dynamiquement des variables de workflow dans votre réponse :

{
  "user": {
    "id": "<variable.userId>",
    "name": "<variable.userName>",
    "email": "<variable.userEmail>"
  },
  "query": "<variable.searchQuery>",
  "results": "<variable.searchResults>",
  "totalFound": "<variable.resultCount>",
  "processingTime": "<variable.executionTime>ms"
}

Les noms de variables sont sensibles à la casse et doivent correspondre exactement aux variables disponibles dans votre workflow.

Bonnes pratiques

  • Utilisez des codes d'état significatifs : choisissez des codes d'état HTTP appropriés qui reflètent précisément le résultat du workflow
  • Structurez vos réponses de manière cohérente : maintenez une structure JSON cohérente pour tous vos endpoints API afin d'améliorer l'expérience développeur
  • Incluez les métadonnées pertinentes : ajoutez des horodatages et des informations de version pour faciliter le débogage et la surveillance
  • Gérez les erreurs avec élégance : utilisez la logique conditionnelle dans votre workflow pour définir des réponses d'erreur appropriées avec des messages descriptifs
  • Validez les références de variables : assurez-vous que toutes les variables référencées existent et contiennent les types de données attendus avant l'exécution du bloc de réponse

On this page