Demande HTTP (HTTP Request)

Configuration du nœud de demande HTTP, authentification et modèles de ramification de la réponse.

Ce qu’il fait

Envoie une demande HTTP à une URL et rend la réponse disponible aux nœuds en aval.

Deux nœuds HTTP

Flow offre deux nœuds HTTP. Choisissez en fonction de la façon dont vous souhaitez gérer l'authentification :

• Demande HTTP (core.action.http) - Configurez la méthode, l'URL, les en-têtes, le corps et l'authentification en ligne. Utilisez-la pour tout point de terminaison REST externe où vous gérez vous-même les identifiants, par exemple un en-tête de clé d'API ou un jeton du porteur. Il s'agit du nœud documenté sur cette page.
• Demande HTTP gérée (core.action.http.v2) - Effectue la demande via une connexion gérée par Integration Service, de sorte que l'authentification est gérée par cette connexion plutôt que configurée en ligne. Utilisez-la lorsque vous souhaitez une gestion centralisée des identifiants pour un service que vous avez connecté via Integration Service.

Référence de la configuration

Champ	Requis	Default	Description
Mode	Oui (Yes)	Manuel	Comment la demande est configurée. Sélectionnez Manuel pour définir vous-même la requête, ou Définition de l'API pour importer la configuration à partir d'une spécification OpenAPI ou Swagger.
Importer à partir d’une commande cURL	Non (No)	Aucun (None)	Analyse une commande cURL et remplit automatiquement la méthode, l'URL, les en-têtes et le corps. Sélectionnez le bouton cURL dans la barre d'outils au-dessus des champs de configuration.
Méthode HTTP	Oui (Yes)	GET	Méthode HTTP pour la requête. Les valeurs prises en charge sont GET, POST, PUT, PATCH, et DELETE.
URL	Oui (Yes)	Aucun (None)	URL complète à laquelle envoyer la demande, y compris le schéma https://. Prend en charge les expressions variables, par exemple https://api.example.com/users/$vars.userId.
En-têtes	Non (No)	Aucun (None)	Paires clé-valeur envoyées en tant qu'en-têtes de demande HTTP. Les noms et les valeurs d'en-tête prennent en charge les expressions variables.
Paramètres de requête	Non (No)	Aucun (None)	Paires clé-valeur ajoutées à l'URL sous forme de chaîne de requête. Les noms et les valeurs prennent en charge les expressions variables.
Type de contenu	Non (No)	application/json	Type Multipurpose Internet Mail Extensions (MIME) du corps de la demande. Les valeurs prises en charge sont application/json, application/xml, text/plain, et application/x-www-form-urlencoded.
Corps	Non (No)	Vide	Corps de la demande pour les requêtes POST, PUT, et PATCH. Entrez la valeur directement dans l'éditeur de code ou utilisez des expressions variables.
branches	Non (No)	Sortie par défaut uniquement	Branches de réponse qui acheminent le processus en fonction des propriétés de réponse. Chaque branche a un nom et une expression de condition.
Délai d'attente	Non (No)	PT15M	Temps maximal pour attendre une réponse, dans le format de durée de l'International Organization for Standardization (ISO) 8601.
Nombre de nouvelles tentatives	Non (No)	0	Nombre de fois pour relancer la demande si elle échoue. Les nouvelles tentatives utilisent la valeur de délai d'expiration comme intervalle de temporisation.

L'éditeur suggère des noms d'en-tête courants tels que Authorization, Content-Type, Accept, X-Api-Key, et d'autres. Pour les paramètres de requête, l'ajout d'un paramètre avec un nom page et une valeur 2 envoie la demande à https://api.example.com/items?page=2.

Le nœud évalue les conditions de la branche dans l'ordre et suit la première correspondance. Si aucune branche ne correspond, le processus suit la sortie par défaut.

Les expressions de condition de branchement utilisent la même syntaxe JavaScript que les nœuds Décision et Basculer :

$vars.httpRequest1.output.statusCode === 200

$vars.httpRequest1.output.statusCode >= 400

Chaque branche apparaît comme un gestionnaire de sortie distinct sur le côté droit du nœud de la zone de dessin, à côté du gestionnaire par défaut.

Valeurs de délai d'expiration courantes :

• PT30S - 30 secondes
• PT5M - 5 minutes
• PT15M - 15 minutes
• PT1H - 1 heure

Identifiants

Vous pouvez authentifier les demandes de deux manières.

Authentification manuelle

Transmettez les identifiants directement dans les en-têtes de demande. Pour l'authentification de la clé d'API, ajoutez un en-tête avec un nom X-Api-Key et une valeur définis à votre clé. Pour l'authentification par jeton du porteur, ajoutez un en-tête Authorization avec une valeur telle que Bearer <your-token>.

Stockez les valeurs sensibles telles que les jetons et les clés d'API dans des variables secrètes plutôt que de les coder en dur.

Connecteur Integration Service

Sélectionnez une connexion Integration Service préconfigurée dans le panneau Propriétés. La connexion injecte automatiquement les identifiants dans la demande, de sorte que vous n'avez pas besoin de gérer vous-même les en-têtes.

Utilisez un connecteur Integration Service lorsque vous souhaitez une gestion centralisée des identifiants, une actualisation automatique des jetons ou lorsque plusieurs processus partagent les mêmes identifiants d'API.

Remarque :

Les connecteurs Integration Service sont configurés dans le portail UiPath Automation Cloud. Reportez-vous à la documentation d'Integration Service pour obtenir des instructions de configuration.

Exemples

Exemple 1 - Demande GET de base

Récupérez une seule ressource à partir d'une API publique.

Le nœud est configuré avec la méthode HTTP définie sur GET et l'URL définie sur https://jsonplaceholder.typicode.com/posts/1. Tous les autres champs restent à leurs valeurs par défaut.

La réponse est disponible dans un nœud Script en aval :

const body = $vars.httpRequest1.output.body;
const status = $vars.httpRequest1.output.statusCode;

return {
  title: body.title,
  userId: body.userId,
  status: status
};

L'objet de réponse est disponible à $vars.httpRequest1.output et contient trois champs :

• $vars.httpRequest1.output.body - le corps de la réponse analysé
• $vars.httpRequest1.output.statusCode - le code de statut HTTP, par exemple 200
• $vars.httpRequest1.output.headers - un olbjet contenant les en-têtes de réponse

Exemple 2 - Demande POST avec un corps JSON

Créez une nouvelle ressource en envoyant une charge utile JSON.

Le nœud est configuré avec la méthode HTTP définie sur POST, l'URL définie sur https://api.example.com/orders, un en-tête Authorization avec la valeur Bearer $vars.apiToken, et le type de contenu laissé comme application/json. Le corps :

{
  "product": "Widget",
  "quantity": 5,
  "customer_id": "cust_12345"
}

L'ID de la ressource créée est disponible dans un nœud en aval :

const orderId = $vars.httpRequest1.output.body.id;
return { orderId: orderId };

Si la requête échoue et que vous avez connecté un gestionnaire d'erreurs, les détails de l'erreur sont disponibles à $vars.httpRequest1.error :

// In a Script node connected to the error handle
const errorMessage = $vars.httpRequest1.error.message;
const errorStatus = $vars.httpRequest1.error.status;

return {
  failed: true,
  reason: errorMessage,
  httpStatus: errorStatus
};

L'objet d'erreur contient :

• code
• message
• detail
• category
• status

Exemple 3 - Acheminement des réponses avec des branches

Les branches de la réponse permettent au processus de suivre différents chemins en fonction de la réponse de l'API sans nœud de décision distinct.

Le nœud est configuré avec la méthode HTTP définie sur GET, l'URL définie sur https://api.example.com/users/$vars.userId, et deux branches dans la section Branches : Success avec condition $vars.httpRequest1.output.statusCode === 200 et Not Found avec condition $vars.httpRequest1.output.statusCode === 404.

Le nœud a désormais trois gestionnaires de sortie sur la zone de dessin :

• Succès - se connecte aux nœuds qui traitent les données utilisateur
• Non trouvé - se connecte aux nœuds qui gèrent le cas utilisateur manquant
• Par défaut - se connecte vers une solution de repli pour tout autre code d'état

Chaque chemin en aval reçoit la réponse complète. Par exemple, sur la branche Succès :

const user = $vars.httpRequest1.output.body;
return { name: user.name, email: user.email };

Quand utiliser cela par rapport à un nœud d'intégration

Utilisez le nœud de demande HTTP comme outil à usage général pour appeler n'importe quelle API. Utilisez un nœud d'intégration dédié lorsqu'il en existe un pour le service que vous appelez.

Utiliser la demande HTTP lorsque...	Utiliser un nœud d'intégration lorsque...
L'API n'a aucun connecteur dédié dans la palette de nœuds	Un connecteur existe pour le service, tel que Slack, Salesforce ou HubSpot
Vous avez besoin d'un contrôle total sur les en-têtes, les paramètres de requête et le format du corps	Vous souhaitez des entrées et des sorties typées pré-construites sans configuration manuelle
Vous créez un prototype pour une nouvelle API ou un service interne	Vous souhaitez l'authentification automatique et l'actualisation des jetons via Integration Service
L'API utilise un schéma d'authentification non standard	Vous souhaitez un processus facile à maintenir qui ne se rompt pas si l'API modifie son contrat

Règle générale : recherchez d'abord un connecteur dans la palette de nœuds. Revenez à la demande HTTP uniquement si rien n'existe pour votre service cible.

Pages liées

• Nœud de script - transformer et traiter les données de réponse HTTP
• Nœud de décision - branche sur les conditions, comme alternative aux branches de réponse
• Variables et flux de données - $vars, syntaxe de l'expression et étendue des variables