# Ce que l’API HTTP de WordPress change lors d’un appel à une API de tarification transporteur

> wp_remote_post impose des délais d'attente par défaut qui ne conviennent pas toujours à un calcul de frais de port en temps réel. Voici comment les ajuster proprement sans casser le tunnel de commande.

- Auteur : WordPress Développement
- Publié le : 2021-06-12
- Mis à jour le : 2021-06-12
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/api-http-wordpress-delais-attente-appel-api-tarification-transporteur/

## L’essentiel

- wp_remote_post applique un délai d'attente par défaut de cinq secondes
- Ce délai s'ajuste par requête via l'argument timeout, jamais globalement à la légère
- Une API transporteur lente doit dégrader gracieusement plutôt que bloquer le tunnel

D'après le Codex de la fonction `wp_remote_post()`, le délai d'attente par défaut d'une requête HTTP sortante déclenchée par WordPress est de cinq secondes. Pour une méthode d'expédition personnalisée qui interroge en temps réel l'API d'un transporteur afin de calculer un tarif exact au moment de la validation du panier, ce chiffre a des conséquences directes sur l'expérience du tunnel de commande : au-delà de cette durée, la requête est interrompue et l'extension doit prévoir un comportement de repli.

Ce billet explique comment fonctionne l'API HTTP de WordPress dans ce contexte, comment ajuster ses délais d'attente correctement, sans entrer dans le choix du transporteur lui-même.

## L'API HTTP de WordPress, une couche d'abstraction unique

Plutôt que d'utiliser directement les fonctions cURL de PHP, WordPress fournit une couche d'abstraction commune, `wp_remote_get()` et `wp_remote_post()`, qui choisit automatiquement le transport disponible sur le serveur (cURL en priorité, sinon les flux natifs de PHP) et applique un jeu d'arguments par défaut cohérent sur toute l'installation.

## Ajuster le délai d'attente pour un appel spécifique

> L'essentiel à retenir : wp_remote_post applique un délai d'attente par défaut de cinq secondes ; Ce délai s'ajuste par requête via l'argument timeout, jamais globalement à la légère ; Une API transporteur lente doit dégrader gracieusement plutôt que bloquer le tunnel

Le délai d'attente se règle via l'argument `timeout`, passé en secondes dans le tableau d'arguments de la requête. Il ne doit jamais être modifié globalement pour l'ensemble du site, ce qui ralentirait toute autre requête sortante, mais ciblé précisément sur l'appel à l'API du transporteur :

```
$reponse = wp_remote_post( 'https://api-transporteur.exemple/tarifs', [
    'timeout' => 8,
    'body'    => wp_json_encode( [
        'poids'         => $poids_colis,
        'code_postal'   => $code_postal_destination,
    ] ),
    'headers' => [ 'Content-Type' => 'application/json' ],
] );

if ( is_wp_error( $reponse ) ) {
    // repli sur un tarif fixe préconfiguré
}
```

Le retour de `wp_remote_post()` est soit un tableau de réponse, soit un objet `WP_Error` en cas d'échec, y compris en cas de dépassement du délai d'attente. Tester systématiquement `is_wp_error()` avant de lire le corps de la réponse évite une notice PHP sur une valeur absente.

## Pourquoi allonger le délai n'est pas toujours la bonne réponse

Augmenter le `timeout` à trente secondes pour « laisser le temps » à une API transporteur lente déplace le problème plutôt que de le résoudre : un client qui valide son panier reste bloqué sur une page de chargement pendant tout ce délai si l'API transporteur ne répond pas. Le bon réflexe consiste à fixer un délai raisonnable, entre cinq et dix secondes, et à prévoir un tarif de repli préconfiguré si l'appel échoue, plutôt que de faire attendre le client indéfiniment.

## Mettre en cache les tarifs obtenus

- Mettre en cache la réponse de l'API transporteur pour un couple poids/destination donné, via l'API Transients de WordPress
- Fixer une durée de cache cohérente avec la fréquence de mise à jour réelle des tarifs du transporteur
- Invalider ce cache manuellement en cas de changement connu de grille tarifaire

```
$cle_cache = 'tarif_transp_' . md5( $poids_colis . $code_postal_destination );
$tarif     = get_transient( $cle_cache );

if ( false === $tarif ) {
    $tarif = appeler_api_transporteur( $poids_colis, $code_postal_destination );
    set_transient( $cle_cache, $tarif, HOUR_IN_SECONDS );
}
```

## Ce que dit la documentation officielle sur les arguments par défaut

La page de référence de `wp_remote_post()` sur developer.wordpress.org liste l'ensemble des arguments disponibles : `timeout`, `redirection`, `httpversion`, `blocking`. L'argument `blocking` à `false` mérite une attention particulière, car il déclenche la requête sans attendre la réponse, ce qui n'a aucun sens pour un calcul de frais de port qui doit être affiché immédiatement au client.

## En résumé

Un calcul de frais de port en temps réel dépend d'un service externe dont la latence échappe totalement au contrôle du site. Ajuster précisément le délai d'attente de `wp_remote_post()`, combiné à un mécanisme de repli et à une mise en cache raisonnable, évite qu'une lenteur ponctuelle du transporteur ne bloque tout le tunnel de commande.