Weave Code
Http Client Laravel Package
symfony/http-client
Symfony HttpClient provides powerful methods to fetch HTTP resources synchronously or asynchronously, with a clean API for building requests, handling responses, streaming, and testing HTTP calls in PHP applications.
Symfony HttpClient is a powerful PHP component for fetching HTTP resources synchronously or asynchronously. It offers a clean, unified API with built-in support for HTTP/2, streaming responses, content decoding, and automatic redirects—making it a solid foundation for any PHP application that consumes web APIs.
It integrates seamlessly with PSR-18 and Symfony contracts, so you can swap clients or combine it with any compatible library.
- Synchronous and asynchronous request handling
- PSR-18 / PSR-17 compliant interfaces
- HTTP/2, gzip, and streaming support
- Built-in retries, redirects, and caching strategies
- Extensible via decorators and scoped clients
Frequently asked questions about Http Client
- How do I install symfony/http-client in a Laravel package?
- Install it with composer require symfony/http-client; you do not need to adopt the full Symfony framework. Then bind Symfony\Component\HttpClient\HttpClientInterface as a singleton in your package service provider and build a configured client from your package config. For broad Laravel compatibility, pin a stable Symfony branch such as ^7.4, or ^6.4|^7.4 if you must support older Laravel versions.
- Is symfony/http-client a drop-in replacement for Laravel's Http facade?
- No. Laravel's Http facade wraps Guzzle, while Symfony HttpClient has its own client interface, decorator model, and error semantics. You should treat it as a package-internal HTTP engine behind a small adapter rather than swapping it in globally. Also note that Laravel's Http::fake() will not intercept Symfony HttpClient requests, so you need MockHttpClient or your own fake layer.
- How can I use Symfony HttpClient inside Laravel without replacing Guzzle?
- Adopt it side-by-side for one bounded integration instead of rewriting existing Guzzle calls. Bind HttpClientInterface in a service provider, construct the client from config for timeouts, retries, base URI, proxy, and concurrency, then expose a package-owned adapter so application code does not depend on Symfony contracts. If a dependency expects PSR-18, use the Psr18Client adapter rather than leaking Symfony types into consumer code. A feature flag or config toggle lets you compare behavior and roll back safely.
- Which Symfony HttpClient version should I require for Laravel compatibility?
- Target ^7.4 as the compatibility anchor for typical modern Laravel applications, or ^6.4|^7.4 if you need to support older Laravel versions. Symfony 8 raises the PHP floor and should be treated as a later PHP 8.4-oriented track rather than the initial target. Avoid anchoring on 8.1.0-BETA1, and pin a stable release after confirming the CVE-2026-48736 fix is present in your chosen branch.
- How do I test Laravel code that uses symfony/http-client?
- Use Symfony's MockHttpClient as the primary testing seam; it is a first-class part of the component and lets you return canned responses and inspect requests. Laravel's Http::fake() will not intercept this client, so ship a package-provided fake or helper if you want a Laravel-style testing API. Many teams use both: MockHttpClient for low-level tests and a package fake for application-facing tests.
- Can I use Laravel's cache with Symfony's CachingHttpClient?
- Not directly. CachingHttpClient expects a PSR-6 cache pool, while Laravel's cache contract is PSR-16, so you need symfony/cache or a custom decorator to bridge the two. Plan this explicitly if decorator-based HTTP caching is part of your design.
- Does symfony/http-client support async requests and concurrency in Laravel?
- Yes. The component supports synchronous and asynchronous requests, streaming, concurrency, retries, redirects, and proxies. Async responses must be consumed or cancelled, and failures surface as exception classes rather than only HTTP status codes. That is powerful for batch API calls, but it is a different programming model from Laravel's Guzzle-based Http facade.
- What are the main risks of using symfony/http-client in a Laravel application?
- The main risk is dual-client fragmentation: some code uses Guzzle via Laravel's Http facade and some uses Symfony HttpClient, with different fakes, logging, and error handling. Symfony HttpClient also has different semantics around async response consumption, exceptions, and decorator-driven retries and caching. Dependency alignment is the second risk because Laravel components constrain symfony/* versions. Keep the integration behind an adapter and pin stable Symfony branches to reduce exposure.
- How do I configure retries, redirects, and observability with Symfony HttpClient in Laravel?
- Use decorators such as RetryableHttpClient for retry behavior, and configure redirects, proxies, timeouts, and base URI when constructing the client from package config. There is no native Laravel integration, so requests will not automatically appear in Telescope, logs, or Laravel events; add your own middleware, events, or adapter-level logging. Keep these concerns in the package adapter so consumer code stays clean.
- Is symfony/http-client well maintained and secure enough for production?
- Yes, maintenance and security handling are strong, with multiple maintained branches and a recent fix for CVE-2026-48736 covering IPv6 transition forms in NoPrivateNetworkHttpClient. The repository's star and dependent counts are misleading because it is a read-only split of the Symfony monorepo, so real adoption is much larger. Still, pin a stable release, verify the CVE fix is backported to your branch, and avoid beta tags for production.
Weaver
How can I help you explore Laravel packages today?