Http Client Laravel Package

Product Decisions This Supports

• Build vs. buy for all outbound HTTP. This is a "buy" (adopt) decision, not a build one: retries, redirects, proxy handling, HTTP/2–HTTP/3 negotiation, streaming, connection pooling, and concurrent fan-out are already implemented and battle-tested. Any team writing a curl_* wrapper or a bespoke retry loop is spending roadmap capacity on undifferentiated, security-sensitive plumbing.
• Feature scope for integrations. The component ships composable decorators that map directly to product requirements: RetryableHttpClient (third-party API flakiness → SLA and support-ticket reduction), ScopingHttpClient (per-tenant base URIs and credentials for multi-tenant SaaS), CachingHttpClient (RFC 9111-compliant caching → latency and egress cost reduction), NoPrivateNetworkHttpClient (SSRF defense for any user-supplied URL feature), and AsyncResponse/stream() (parallel enrichment for dashboards and search).
• Roadmap bets on latency and cost. Async concurrency lets a PM commit to "aggregate 8 partner APIs in one request" without a queue-and-poll architecture. Streaming responses unlock incremental UI (server-sent payload relay) and large-file proxying without buffering the whole body in memory.
• Architecture and interop decisions. PSR-18/PSR-17 adapters (Psr18Client, HttplugClient) plus a GuzzleHttpHandler bridge mean the choice is reversible and doesn't lock the org into a single HTTP stack — relevant when deciding whether Laravel's Http facade (Guzzle-backed) remains the house standard.
• Testing strategy. MockHttpClient and the copy-as-curl/debug tooling raise the ceiling on integration-test coverage for external dependencies, which is usually where PM-visible regressions ("checkout fails when the payments API is slow") originate.
• Security posture decisions. Recent releases include a CVE fix (IPv6 transition forms in NoPrivateNetworkHttpClient) and a cross-authority redirect credential-leak fix. That is a signal to set an explicit patch-SLA and advisory-monitoring policy for outbound HTTP rather than letting transitive versions drift.

When to Consider This Package

Adopt when:

• You have any meaningful volume of server-side outbound HTTP — partner APIs, webhooks, data syncs, AI/LLM providers — and care about retries, timeouts, concurrency, and redirect/proxy correctness.
• You need concurrent fan-out but don't want to introduce a job queue or an async runtime; the synchronous API plus async responses keeps the codebase conventional.
• You ship multi-tenant or multi-vendor integrations requiring per-scope base URIs and headers (ScopingHttpClient).
• You fetch user-supplied URLs and need SSRF controls built in rather than reinvented per feature.
• You are already on Symfony components (or Laravel, which already depends on a large slice of Symfony) and can absorb one more component without expanding your dependency surface philosophically.
• You want a PSR-18-compatible client so the transport can be swapped later without rewriting call sites.

Look elsewhere, or pause, when:

• The org is standardized on Laravel's Http facade. Running Guzzle and this component means two transports, two mocking idioms, and two sets of timeout semantics. Adopt only with an explicit migration or a deliberate "new code only" boundary; a split-brain HTTP stack is a real maintenance tax.
• You need an off-the-shelf, vendor-supported product with SLAs. This is a volunteer-maintained open-source component under the Symfony umbrella — excellent, but not a commercial support contract.
• You need heavy middleware/plugin ecosystems (Guzzle's plugin library, signing packages, provider SDKs). Some SDKs hard-depend on Guzzle's interfaces; the GuzzleHttpHandler bridge helps, but SDK compatibility must be verified case by case.
• Your workload is browser-side or edge-side — this is a PHP server component, not a frontend or CDN tool.
• Governance evidence is thin for your process. Be explicit internally: the repository evaluated here is a read-only split of symfony/symfony (issues and PRs live in the monorepo), which explains the reported 0 dependents and modest star count. Real adoption is ecosystem-wide and flows through the monorepo. Treat the star/dependent numbers as not a demand signal either way; weigh the Symfony release policy, LTS lines (5.4/6.4), and the steady bugfix backports in the changelog instead.
• You require a single, pinned major with long support. Symfony majors move fast (7.4 → 8.1 within the window). Confirm which line you'll standardize on (LTS vs. latest) before committing.

How to Pitch It (Stakeholders)

For executives: Outbound HTTP is the connective tissue of our integrations, and it's also where outages and security incidents hide. This component replaces hand-rolled request code with a mature, MIT-licensed library that already handles retries, timeouts, proxies, redirects, HTTP/2–3, caching, and SSRF protection — maintained by the Symfony project with backports to long-term-support branches and a recent CVE fix shipped as a patch. Buying (adopting) this means faster delivery of integration features, fewer bespoke bugs, and a smaller security surface, at zero license cost. The main cost is engineering discipline — one transport standard, version pinning, and advisory monitoring — not procurement.

For engineering: Composable clients let you layer exactly what each integration needs: RetryableHttpClient for flaky partners, ScopingHttpClient for per-tenant credentials, CachingHttpClient for RFC 9111 cache behavior, NoPrivateNetworkHttpClient for user-supplied URLs. Async responses give concurrency without a queue. PSR-18/PSR-17 adapters and the Guzzle handler keep us portable. Two cautions: (1) this is a split repo of symfony/symfony — track issues and security advisories upstream, not here; (2) if we stay on Laravel's Http facade, declare a hard boundary so we don't end up maintaining two HTTP stacks. Pin to an LTS line, subscribe to Symfony security announcements, and set a patch window (e.g., 7 days for security releases).

Decision requested: approve adopting this as the standard outbound HTTP client for new integration code, conditional on (a) an LTS version pin, (b) a documented coexistence rule with the existing HTTP layer, and (c) a named owner for security-advisory monitoring.