PHP HTTP-Client im Vergleich: Guzzle, Symfony HttpClient, PSR-18

1. Warum der HTTP-Client die Basis jeder API-Integration ist

Kaum eine moderne PHP-Anwendung kommt ohne ausgehende HTTP-Anfragen aus. Ob REST-Aufrufe an ein Warenwirtschaftssystem, eingehende Webhooks von einem Payment-Gateway, die Kommunikation zwischen Microservices oder das Abrufen von Wechselkursen bei einem externen Anbieter: In jedem dieser Fälle steht ein PHP HTTP-Client zwischen der eigenen Anwendung und der Außenwelt. Wie robust dieser Client konfiguriert ist, entscheidet direkt darüber, ob ein einzelner langsamer Drittanbieter die gesamte Anwendung blockiert oder ob Fehler sauber abgefangen und behandelt werden.

Die Wahl des HTTP-Clients wirkt sich auf weit mehr aus als nur den reinen Funktionsaufruf. Timeout-Verhalten, Retry-Logik, Verbindungs-Pooling, Testbarkeit im Unit-Test und die Interoperabilität mit Drittanbieter-Bibliotheken hängen alle von dieser einen Entscheidung ab. Ein Payment-Gateway, das nach zwei Sekunden nicht antwortet, darf den Checkout-Prozess nicht für dreißig Sekunden einfrieren. Ein Webhook-Consumer muss auf fehlerhafte Antworten reagieren können, ohne den gesamten Request-Handler abstürzen zu lassen. Genau hier zeigt sich, warum ein durchdachter PHP HTTP-Client kein Implementierungsdetail ist, sondern eine strategische Architekturentscheidung.

Historisch griffen PHP-Entwickler direkt zu curl_init(), weil die Extension seit Jahrzehnten Teil jeder Standardinstallation ist. Mit dem Aufkommen von Composer und dem PSR-Standardisierungsprozess hat sich das Feld jedoch deutlich erweitert: Guzzle etablierte sich als De-facto-Standard-Bibliothek, Symfony HttpClient brachte einen performanceorientierten Ansatz mit Streaming und HTTP/2, und PSR-18 schuf erstmals eine gemeinsame Schnittstelle, gegen die Bibliotheksautoren programmieren können, ohne sich auf eine konkrete Implementierung festzulegen.

2. cURL direkt in PHP: Möglichkeiten und Grenzen des Low-Level-Ansatzes

Die cURL-Extension bildet das Fundament, auf dem praktisch jeder PHP HTTP-Client letztlich aufbaut, auch Guzzle nutzt sie standardmäßig als Handler. Direkt genutzt bedeutet das: curl_init() erzeugt ein Handle, curl_setopt_array() konfiguriert Methode, Header, Body, Timeouts und SSL-Verhalten, und curl_exec() führt die Anfrage synchron aus. Für einzelne, einfache Requests funktioniert das zuverlässig, doch der Ansatz zeigt schnell seine Grenzen: Jede Fehlerbehandlung, jedes Timeout-Handling und jede Retry-Logik muss manuell implementiert werden, es gibt keine eingebaute Middleware-Architektur und keine PSR-Kompatibilität.

Für parallele Anfragen bietet cURL die curl_multi_*-Funktionsfamilie an. curl_multi_init() erzeugt einen Multi-Handle, dem mehrere einzelne cURL-Handles hinzugefügt werden, danach treibt eine Schleife mit curl_multi_exec() und curl_multi_select() alle Anfragen gemeinsam voran. Das funktioniert, ist aber deutlich fehleranfälliger als die Promise-basierten Abstraktionen moderner Bibliotheken, weil der Entwickler selbst für korrektes Event-Handling, Fehlerpropagation und das Einsammeln der Ergebnisse verantwortlich ist.

Der größte Vorteil von rohem cURL liegt in der Kontrolle: Keine zusätzliche Composer-Abhängigkeit, volle Sichtbarkeit auf jede einzelne Option, und keine Abstraktionsebene, die im Debugging im Weg steht. In sehr kleinen Skripten, CLI-Tools ohne Composer-Setup oder Umgebungen mit strikten Dependency-Vorgaben ist das nach wie vor eine legitime Wahl. Für größere Anwendungen mit vielen externen Integrationen wird der fehlende Standardisierungsgrad jedoch schnell zur Wartungslast, weil jede Codebasis ihre eigene Variante von Error-Handling und Retry-Logik erfindet.

<?php

declare(strict_types=1);

/**
 * Minimal raw cURL request with explicit error handling.
 * No abstraction layer, full control over every option.
 */
function fetchOrderStatus(string $orderId, string $apiToken): array
{
    $ch = curl_init();

    curl_setopt_array($ch, [
        CURLOPT_URL => "https://api.example.com/orders/{$orderId}/status",
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CUSTOMREQUEST => 'GET',
        CURLOPT_HTTPHEADER => [
            "Authorization: Bearer {$apiToken}",
            'Accept: application/json',
        ],
        CURLOPT_CONNECTTIMEOUT => 3,
        CURLOPT_TIMEOUT => 10,
        CURLOPT_SSL_VERIFYPEER => true,
        CURLOPT_SSL_VERIFYHOST => 2,
    ]);

    $body = curl_exec($ch);
    $errno = curl_errno($ch);

    if ($errno !== 0) {
        $error = curl_error($ch);
        curl_close($ch);
        throw new RuntimeException("cURL error ({$errno}): {$error}");
    }

    $statusCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);

    if ($statusCode >= 400) {
        throw new RuntimeException("API returned HTTP {$statusCode}");
    }

    /** @var array $decoded */
    $decoded = json_decode((string) $body, true, flags: JSON_THROW_ON_ERROR);

    return $decoded;
}

3. Guzzle im Detail: Architektur, Middleware-Stack und Promises

Guzzle ist der bekannteste PHP HTTP-Client im Composer-Ökosystem und wird von unzähligen SDKs, Frameworks und internen Tools als Abhängigkeit vorausgesetzt. Die zentrale Idee hinter Guzzle ist der HandlerStack: Eine Kette aus Middleware-Funktionen, die jede ausgehende Anfrage und jede eingehende Antwort durchläuft, bevor sie das eigentliche Handler-Backend erreicht oder an den Aufrufer zurückgegeben wird. Dieses Middleware-Konzept erlaubt es, Logging, Retry-Logik, Authentifizierung oder Caching als eigenständige, wiederverwendbare Bausteine zu implementieren, ohne den eigentlichen Request-Code anzufassen.

Eine eigene Middleware ist dabei nichts anderes als eine höhere Funktion, die einen Handler entgegennimmt und einen neuen Handler zurückgibt. Guzzle stellt bereits eingebaute Middleware für Retry-Verhalten (Middleware::retry()) und History-Tracking bereit, eigene Middleware für Logging oder das Anreichern von Headern lässt sich mit wenigen Zeilen ergänzen und über $handlerStack->push() in den Stack einhängen. Diese Erweiterbarkeit ist einer der Hauptgründe, warum Guzzle sich als PHP HTTP-Client so breit durchgesetzt hat.

Neben synchronen Requests unterstützt Guzzle asynchrone Anfragen über Promises aus der Bibliothek guzzlehttp/promises. Statt $client->get() ruft man $client->getAsync() auf und erhält sofort ein Promise-Objekt zurück, während die Anfrage im Hintergrund läuft. Mehrere Promises lassen sich mit Utils::unwrap() oder Promise\Utils::settle() gemeinsam auflösen, was parallele Requests ohne manuelles Multi-Handle-Management ermöglicht. Diese Kombination aus Middleware-Stack und Promise-basierter Async-API macht Guzzle zu einem der ausgereiftesten HTTP-Clients im PHP-Ökosystem.

<?php

declare(strict_types=1);

use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Middleware;
use GuzzleHttp\Promise\Utils;
use Psr\Http\Message\RequestInterface;
use Psr\Http\Message\ResponseInterface;
use Psr\Log\LoggerInterface;

/**
 * Custom logging middleware for the Guzzle handler stack.
 * Logs method, URI and response status without touching call sites.
 */
function createLoggingMiddleware(LoggerInterface $logger): callable
{
    return function (callable $handler) use ($logger): callable {
        return function (RequestInterface $request, array $options) use ($handler, $logger) {
            $logger->info('HTTP request sent', [
                'method' => $request->getMethod(),
                'uri' => (string) $request->getUri(),
            ]);

            return $handler($request, $options)->then(
                function (ResponseInterface $response) use ($logger, $request) {
                    $logger->info('HTTP response received', [
                        'uri' => (string) $request->getUri(),
                        'status' => $response->getStatusCode(),
                    ]);
                    return $response;
                }
            );
        };
    };
}

$stack = HandlerStack::create();
$stack->push(createLoggingMiddleware($logger));
$stack->push(Middleware::retry(
    decider: fn (int $retries, $request, $response = null, $exception = null) =>
        $retries < 3 && ($exception !== null || $response?->getStatusCode() >= 500),
    delay: fn (int $retries) => 1000 * (2 ** $retries),
));

$client = new Client(['handler' => $stack, 'timeout' => 10.0]);

// Async requests resolved together via promises
$promises = [
    'orders' => $client->getAsync('https://api.example.com/orders'),
    'customers' => $client->getAsync('https://api.example.com/customers'),
];

$responses = Utils::unwrap($promises);
echo $responses['orders']->getStatusCode();

4. Symfony HttpClient: Design, HttpClientInterface und Streaming

Symfony HttpClient verfolgt einen anderen architektonischen Ansatz als Guzzle. Statt eines Middleware-Stacks basiert die Komponente auf lazy responses: Ein Aufruf über HttpClient::create()->request() gibt sofort ein Response-Objekt zurück, ohne dass die Anfrage bereits vollständig ausgeführt wurde. Erst wenn tatsächlich auf Daten zugegriffen wird, etwa mit getStatusCode() oder getContent(), blockiert der Aufruf und wartet auf die Antwort. Dieses Design erlaubt es, mehrere Requests nacheinander zu starten, ohne explizit async/await-Syntax oder Promises zu benötigen, und dennoch Nebenläufigkeit zu erreichen.

Ein weiteres Kernmerkmal ist natives Streaming. Mit $httpClient->stream($response) lässt sich eine Antwort in Chunks konsumieren, sobald sie eintreffen, statt auf den vollständigen Body zu warten. Das ist besonders wertvoll beim Verarbeiten großer JSON-Exporte, beim Weiterleiten von Datei-Downloads an den Client oder beim Konsumieren von Server-Sent-Events-ähnlichen Endpunkten, bei denen Daten kontinuierlich nachgeliefert werden. Die Implementierung von HttpClientInterface unterstützt zudem automatisch HTTP/2, sofern die zugrunde liegende cURL-Version und der Server dies zulassen.

Da Symfony HttpClient von Anfang an gegen PSR-18 kompatibel gestaltet wurde (über den Psr18Client-Adapter), lässt sich die Komponente auch in Bibliotheken einsetzen, die eine PSR-konforme Abhängigkeit erwarten. Für Projekte, die bereits andere Symfony-Komponenten nutzen oder auf maximale Performance bei vielen parallelen Anfragen angewiesen sind, ist das oft der überzeugendere PHP HTTP-Client als der klassische Guzzle-Ansatz.

<?php

declare(strict_types=1);

use Symfony\Component\HttpClient\HttpClient;
use Symfony\Contracts\HttpClient\ChunkInterface;
use Symfony\Contracts\HttpClient\ResponseInterface;

$httpClient = HttpClient::create([
    'timeout' => 10,
    'max_redirects' => 3,
]);

// Lazy response: the request only starts consuming data on access
$response = $httpClient->request('GET', 'https://api.example.com/export/large-dataset', [
    'headers' => ['Accept' => 'application/x-ndjson'],
]);

$buffer = '';

/**
 * Stream the response body chunk by chunk instead of
 * waiting for the full payload to be buffered in memory.
 */
foreach ($httpClient->stream($response) as $chunk) {
    /** @var ChunkInterface $chunk */
    $buffer .= $chunk->getContent();

    while (($newlinePos = strpos($buffer, "\n")) !== false) {
        $line = substr($buffer, 0, $newlinePos);
        $buffer = substr($buffer, $newlinePos + 1);

        if ($line !== '') {
            $record = json_decode($line, true, flags: JSON_THROW_ON_ERROR);
            processExportRecord($record);
        }
    }
}

if ($response->getStatusCode() >= 400) {
    throw new RuntimeException('Export request failed: ' . $response->getStatusCode());
}

5. PSR-18, PSR-17 und PSR-7: Standardisierung und Interoperabilität

PSR-18 definiert eine einzige, minimale Schnittstelle für einen PHP HTTP-Client: Psr\Http\Client\ClientInterface mit genau einer Methode, sendRequest(), die eine PSR-7-Anfrage entgegennimmt und eine PSR-7-Antwort zurückgibt. Diese bewusste Kleinheit ist der entscheidende Vorteil: Eine Bibliothek, die gegen PSR-18 programmiert, ist völlig unabhängig davon, ob am Ende Guzzle, Symfony HttpClient oder eine andere Implementierung die Anfrage tatsächlich ausführt. Der Konsument der Bibliothek entscheidet per Dependency Injection, welcher konkrete Client verwendet wird.

Damit dieses Zusammenspiel funktioniert, braucht es zusätzlich PSR-17, die Factory-Interfaces für PSR-7-Objekte, allen voran RequestFactoryInterface, StreamFactoryInterface und UriFactoryInterface. Eine Bibliothek, die PSR-18 und PSR-17 gemeinsam nutzt, muss keine PSR-7-Implementierung wie nyholm/psr7 oder guzzlehttp/psr7 fest voraussetzen, sondern lässt sich diese Fabriken ebenfalls injizieren. Genau das macht Pakete wie SDKs für Zahlungsanbieter oder API-Wrapper unabhängig von der konkreten HTTP-Stack-Wahl des Endnutzers.

Für Bibliotheksautoren ist das kein akademisches Detail, sondern ein handfester Vorteil im Composer-Ökosystem: Ein SDK, das PSR-18 statt einer festen Guzzle-Abhängigkeit voraussetzt, verursacht keine Versionskonflikte, wenn eine Anwendung bereits Symfony HttpClient nutzt. discovery-Pakete wie php-http/discovery ermitteln zur Laufzeit automatisch, welche PSR-18-Implementierung im Projekt verfügbar ist, sodass Endnutzer oft gar keine explizite Konfiguration vornehmen müssen.

<?php

declare(strict_types=1);

use Psr\Http\Client\ClientExceptionInterface;
use Psr\Http\Client\ClientInterface;
use Psr\Http\Message\RequestFactoryInterface;
use Psr\Http\Message\StreamFactoryInterface;

/**
 * Framework-agnostic API client depending only on PSR-18 and PSR-17.
 * Works unchanged with Guzzle, Symfony HttpClient or any other
 * PSR-18 compatible implementation injected by the consumer.
 */
final readonly class WeatherApiClient
{
    public function __construct(
        private ClientInterface $httpClient,
        private RequestFactoryInterface $requestFactory,
        private StreamFactoryInterface $streamFactory,
        private string $apiBaseUrl,
        private string $apiKey,
    ) {
    }

    /**
     * Fetches current weather data for a given city.
     *
     * @param string $city City name used as the query parameter.
     * @return array<string, mixed> Decoded JSON payload.
     * @throws ClientExceptionInterface When the underlying transport fails.
     * @throws RuntimeException When the API returns a non-success status.
     */
    public function getCurrentWeather(string $city): array
    {
        $uri = "{$this->apiBaseUrl}/current?city=" . urlencode($city);

        $request = $this->requestFactory
            ->createRequest('GET', $uri)
            ->withHeader('Authorization', "Bearer {$this->apiKey}")
            ->withHeader('Accept', 'application/json');

        $response = $this->httpClient->sendRequest($request);

        if ($response->getStatusCode() >= 400) {
            throw new RuntimeException("Weather API returned HTTP {$response->getStatusCode()}");
        }

        /** @var array<string, mixed> $decoded */
        $decoded = json_decode((string) $response->getBody(), true, flags: JSON_THROW_ON_ERROR);

        return $decoded;
    }
}

6. Retry-Strategien, Timeouts und Connection-Pooling richtig konfigurieren

Ein Timeout ist keine einzelne Zahl, sondern mindestens zwei getrennte Werte: connect_timeout begrenzt, wie lange auf den Aufbau der TCP-Verbindung gewartet wird, während timeout die Gesamtdauer der gesamten Anfrage inklusive Datenübertragung limitiert. Wer beide auf denselben Wert setzt, riskiert entweder zu aggressive Abbrüche bei langsamen, aber funktionierenden Verbindungen, oder viel zu lange Wartezeiten, wenn ein Server zwar erreichbar ist, aber nie antwortet. Ein sinnvoller Ausgangspunkt für die meisten API-Integrationen liegt bei zwei bis drei Sekunden für den Connect-Timeout und fünf bis fünfzehn Sekunden für den Gesamt-Timeout, abhängig von der erwarteten Antwortzeit des Zielsystems.

Retry-Logik sollte niemals blind jeden Fehler wiederholen. Ein 4xx-Statuscode wie 400 oder 404 signalisiert ein Problem auf Client-Seite, das ein erneuter Versuch nicht behebt, während 5xx-Statuscodes und Verbindungsfehler durchaus transiente Probleme darstellen können, für die sich ein Retry lohnt. Exponential Backoff, bei dem die Wartezeit zwischen Versuchen exponentiell steigt (zum Beispiel 100ms, 200ms, 400ms, 800ms), verhindert, dass ein bereits überlasteter Server durch aggressive Wiederholungsversuche zusätzlich unter Druck gerät. Sowohl Guzzle über Middleware::retry() als auch Symfony HttpClient über den RetryableHttpClient-Decorator bieten diese Strategie eingebaut an.

Connection-Pooling und Keep-Alive-Verbindungen reduzieren den Overhead wiederholter TLS-Handshakes erheblich, wenn eine Anwendung viele Anfragen an denselben Host stellt. Sowohl Guzzle als auch Symfony HttpClient nutzen darunter cURL-Handles, die Verbindungen standardmäßig für nachfolgende Requests an denselben Host wiederverwenden, solange derselbe Client (beziehungsweise dieselbe cURL-Multi-Instanz) über die Laufzeit hinweg bestehen bleibt. Ein neues Client-Objekt für jede einzelne Anfrage zu instanziieren, zerstört diesen Vorteil und erzwingt bei jedem Aufruf einen kompletten Verbindungsaufbau.

7. HTTP-Clients testen: Mocking mit Guzzle MockHandler und Symfony MockHttpClient

Unit-Tests dürfen niemals echte Netzwerk-Calls auslösen, sie wären langsam, unzuverlässig und abhängig von der Verfügbarkeit externer Systeme. Guzzle bietet dafür den MockHandler: Statt eines echten HTTP-Handlers wird eine Warteschlange vordefinierter Response-Objekte oder Exceptions in den HandlerStack eingehängt, sodass jeder Aufruf im getesteten Code exakt die konfigurierte Antwort erhält, ohne dass eine Netzwerkverbindung aufgebaut wird. Weil der Rest der Anwendung weiterhin gegen die normale ClientInterface programmiert, unterscheidet sich der getestete Code nicht vom Produktionscode.

Symfony HttpClient bietet mit MockHttpClient einen vergleichbaren Mechanismus: Callbacks oder vorbereitete MockResponse-Objekte simulieren beliebige Statuscodes, Header und Body-Inhalte, inklusive simuliertem Streaming-Verhalten für Tests von Chunk-basiertem Code. Beide Ansätze erlauben es zusätzlich, Netzwerkfehler wie Verbindungsabbrüche oder Timeouts gezielt zu simulieren, was in der Praxis oft wichtiger ist als der Erfolgsfall, weil genau dieser Pfad in echten Integrationen am seltensten manuell getestet wird.

Wer PSR-18 als Abhängigkeit nutzt, profitiert im Testing zusätzlich davon, dass sich jede beliebige PSR-18-kompatible Test-Implementierung injizieren lässt, ohne dass die getestete Klasse etwas von Guzzle oder Symfony HttpClient weiß. Das reduziert Kopplung im Test-Setup und macht es möglich, denselben Servicecode gegen unterschiedliche Mock-Implementierungen zu verifizieren, falls ein Projekt zwischen mehreren HTTP-Client-Bibliotheken wechselt.

<?php

declare(strict_types=1);

namespace App\Tests;

use GuzzleHttp\Client;
use GuzzleHttp\Handler\MockHandler;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Psr7\Response;
use PHPUnit\Framework\TestCase;

/**
 * Verifies WeatherApiService behavior without any real network call,
 * using Guzzle's MockHandler to queue predefined responses.
 */
final class WeatherApiServiceTest extends TestCase
{
    public function testReturnsDecodedTemperatureOnSuccess(): void
    {
        $mock = new MockHandler([
            new Response(200, ['Content-Type' => 'application/json'], (string) json_encode([
                'city' => 'Berlin',
                'temperature' => 21.5,
            ])),
        ]);

        $handlerStack = HandlerStack::create($mock);
        $client = new Client(['handler' => $handlerStack]);

        $service = new WeatherApiService($client);
        $result = $service->getTemperature('Berlin');

        self::assertSame(21.5, $result);
    }

    public function testThrowsOnServerError(): void
    {
        $mock = new MockHandler([
            new Response(503, [], 'Service Unavailable'),
        ]);

        $client = new Client(['handler' => HandlerStack::create($mock)]);
        $service = new WeatherApiService($client);

        $this->expectException(\RuntimeException::class);
        $service->getTemperature('Berlin');
    }
}

8. Performance: HTTP/2, Multiplexing und parallele Requests

HTTP/2 erlaubt Multiplexing, das heißt mehrere Anfragen und Antworten laufen gleichzeitig über eine einzige TCP-Verbindung, statt für jede Anfrage einen neuen Handshake zu benötigen. Für Anwendungen, die viele kleine Requests an denselben Host senden, etwa beim Abrufen mehrerer Ressourcen von einer API mit vielen einzelnen Endpunkten, reduziert das die Latenz spürbar. Symfony HttpClient aktiviert HTTP/2 automatisch, sofern die verwendete cURL-Version es unterstützt und der Server ebenfalls HTTP/2 anbietet, ohne dass der Entwickler dafür Konfiguration ändern muss.

Für parallele Requests bietet Guzzle den Pool-Mechanismus: Ein Generator liefert eine konfigurierbare Anzahl von Requests, während Pool::batch() oder eine manuell konfigurierte Concurrency dafür sorgt, dass niemals mehr als eine definierte Anzahl gleichzeitiger Verbindungen offen ist. Das verhindert, dass tausend parallele Requests einen Zielserver überlasten oder das eigene System durch zu viele offene Sockets destabilisieren. Symfony HttpClient erreicht denselben Effekt durch die bereits erwähnten lazy responses: Mehrere request()-Aufrufe werden nacheinander gestartet, laufen aber im Hintergrund nebenläufig, bis ihre Ergebnisse tatsächlich abgefragt werden.

In Benchmarks mit vielen kleinen, parallelen Requests an denselben Host liegt Symfony HttpClient durch native HTTP/2-Unterstützung und die effiziente lazy-response-Architektur häufig leicht vorne. Für Anwendungsfälle mit wenigen, aber komplexen Requests, bei denen Middleware-Logik wie Logging, Auth-Refresh oder Retry im Vordergrund steht, überzeugt Guzzle durch seinen ausgereiften Middleware-Stack. Die folgende Tabelle fasst die wichtigsten Entscheidungskriterien zusammen.

9. Den richtigen HTTP-Client auswählen: Entscheidungskriterien für Projekte

Die Wahl des passenden PHP HTTP-Client hängt stark von der Projektgröße ab. Ein kleines CLI-Tool oder Skript ohne bestehende Composer-Abhängigkeiten kann mit rohem cURL auskommen, insbesondere wenn nur ein einziger, einfacher Request benötigt wird. Sobald mehrere Endpunkte, Retry-Logik oder Middleware-Anforderungen ins Spiel kommen, überwiegt der Aufwand für eigenes Error-Handling schnell den Overhead einer zusätzlichen Bibliothek.

Bestehende Dependencies sind oft der entscheidende Faktor: Ein Projekt, das bereits Symfony-Komponenten wie den Messenger oder den Mailer nutzt, profitiert vom nahtlosen Zusammenspiel mit Symfony HttpClient, inklusive gemeinsamer Konfiguration und Event-Dispatching. Ein Projekt mit vielen bestehenden Guzzle-basierten SDKs, etwa für AWS oder diverse Payment-Provider, spart sich Konflikte und doppelte HTTP-Stacks, indem es konsequent bei Guzzle bleibt. Wer eine eigene Bibliothek oder ein SDK für Dritte entwickelt, sollte praktisch immer PSR-18 und PSR-17 als Abhängigkeit wählen und die konkrete Implementierung dem Konsumenten überlassen.

Testbarkeit und langfristige Wartung sprechen fast immer für eine der etablierten Bibliotheken statt rohem cURL, weil Mocking, Middleware und Community-Support den Wartungsaufwand über die Projektlaufzeit erheblich reduzieren. Für neue Projekte ohne bestehende Festlegung ist eine pragmatische Faustregel: Guzzle, wenn Middleware-Flexibilität und das riesige Ökosystem an fertigen SDKs im Vordergrund stehen, Symfony HttpClient, wenn Performance bei vielen parallelen Requests und natives Streaming wichtiger sind, und in jedem Fall PSR-18 als Schnittstelle im eigenen Anwendungscode, um die konkrete Wahl später ohne größeren Umbau ändern zu können.

10. Zusammenfassung

Der richtige PHP HTTP-Client ist selten eine reine Geschmacksfrage. Rohes cURL bietet maximale Kontrolle ohne Abhängigkeiten, verlangt aber manuelles Error-Handling und Retry-Logik für jeden einzelnen Anwendungsfall. Guzzle etabliert sich durch seinen Middleware-Stack und die riesige Verbreitung als sicherer Standardgriff für die meisten Projekte, während Symfony HttpClient mit lazy responses, nativem HTTP/2 und effizientem Streaming bei performancekritischen, parallelen Workloads punktet.

PSR-18 und PSR-17 lösen das eigentliche Interoperabilitätsproblem: Sie erlauben es, Bibliotheken und Anwendungscode unabhängig von der konkreten HTTP-Client-Implementierung zu schreiben. Wer heute eine neue Integration beginnt, sollte gegen diese Interfaces programmieren, sauber konfigurierte Timeouts und Retry-Strategien mit exponential backoff einplanen, und von Anfang an mit MockHandler oder MockHttpClient testen, statt echte Netzwerk-Calls in die Test-Suite einzubauen.

11. FAQ: PHP HTTP-Client im Vergleich