Laravel 12.44 : afterResponse() du HTTP Client, assertHeader et validation de dates

Laravel 12.44 apporte notamment : afterResponse() sur le HTTP Client (exécuter un callback après la réception de la réponse), assertHeader() pour les tests de réponse, et des règles de validation de dates plus expressives (Date::parseable(), beforeOrEqual, etc.). Voici comment les utiliser.

Prérequis

• Projet Laravel 12.x (ou 11 selon backports)
• Utilisation du HTTP Client (Illuminate\Support\Facades\Http) et des tests HTTP

1. afterResponse() sur le HTTP Client

afterResponse() permet d’attacher un callback exécuté après que la réponse HTTP soit construite. Utile pour : journalisation, détection de dépréciations (headers type X-API-Deprecated-Reason), transformation de la réponse en DTO, etc.

Exemple simple : log

use Illuminate\Support\Facades\Http;

return Http::acceptJson()
    ->withHeader('X-Shopify-Access-Token', $shopCreds->token)
    ->baseUrl("https://{$shopCreds->shop_domain}.myshopify.com/admin/api/2025-10/")
    ->afterResponse(function (Response $response) {
        logger()->info('Réponse reçue', ['status' => $response->status()]);
    })
    ->get('products.json');

Détection de dépréciation (ex. Shopify)

->afterResponse(function (Response $response) use ($shopCreds) {
    $header = $response->header('X-Shopify-API-Deprecated-Reason');
    if ($header) {
        event(new ShopifyDeprecationNotice($shopCreds->shop, $header));
    }
})
->get('orders.json');

Transformer la réponse en objet

Le callback peut retourner une nouvelle valeur, qui remplace la réponse par défaut :

->afterResponse(fn (Response $response) => new ShopifyResponse($response->toPsrResponse()))

Utile pour wraper la réponse dans un DTO ou normaliser des réponses d’API tierces.

2. assertHeader() dans les tests

assertHeader() vérifie la présence d’un en-tête et, optionnellement, sa valeur :

$response->assertHeader('X-RateLimit-Remaining');
$response->assertHeader('Content-Type', 'application/json');

Les assertions sont insensibles à la casse pour le nom de l’en-tête. Pratique pour les APIs, le rate limiting et les en-têtes de cache.

3. Règles de validation de dates (fluent)

Laravel 12.44 améliore les règles de dates avec des helpers fluent :

use Illuminate\Validation\Rules\Date;

$request->validate([
    'start_date' => [
        'required',
        Date::parseable()->beforeOrEqual('today'),
    ],
]);

Date::parseable() garantit que la valeur est une date valide ; beforeOrEqual('today'), after(), afterOrEqual(), etc. permettent d’exprimer les contraintes de façon lisible. Adapté aux réservations, périodes d’abonnement, rapports et événements.

Dépannage

Bonnes pratiques

• Utiliser afterResponse() pour tout ce qui est observabilité ou post-traitement de la réponse (logs, métriques, dépréciations), afin de garder la logique métier plus propre.
• Dans les tests, assertHeader() pour documenter et verrouiller le contrat des en-têtes (CORS, rate limit, content-type).
• Date::parseable() et les contraintes fluent pour toutes les dates (événements, abonnements, rapports) afin de limiter les erreurs de validation ad hoc.

Ressources

• Tech Verse Daily – Laravel 12.44 afterResponse()
• Changelog Laravel 12.x
• Documentation Laravel – HTTP Client

Cet article s’inscrit dans notre série de guides technique et développement web. Pour un serveur ou une application sur-mesure, contact.