Http Client Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony bundle, not a Laravel package. There is no service provider, no auto-discovery, no facade, and no config/ publish step. A composer require weblabel/http-client-bundle in a Laravel app will install files you cannot bootstrap through Laravel's container without manual wiring. Treat the "Laravel developer" framing as: what would I actually do with this in a Laravel codebase, and when would I reach for it?

In a Symfony app (its intended home):

1. composer require weblabel/http-client-bundle
2. Register the bundle in config/bundles.php:

   Weblabel\HttpClientBundle\WeblabelHttpClientBundle::class => ['all' => true],
   

3. Add config under config/packages/weblabel_http_client.yaml (verify the exact root key by reading src/DependencyInjection/Configuration.php — the README is thin and the tree is authoritative).
4. First use case: autowire the bundle's client service/interface into a controller or console command and make one GET call, logging the response status and body.

Where to look first, in order:

• src/DependencyInjection/Configuration.php — every config key and default.
• src/DependencyInjection/WeblabelHttpClientExtension.php — how services are built and aliased.
• src/Resources/config/*.xml|yaml — the actual service IDs and constructor arguments.
• The client class itself — is it wrapping Symfony HttpClient, a PSR-18 client, or Guzzle? This determines everything downstream.

In a Laravel app: don't install it casually. Laravel already ships Illuminate\Support\Facades\Http (Guzzle-backed) with retry(), timeout(), withHeaders(), fakeable tests, and first-class container binding. The only legitimate reasons to touch this bundle from Laravel are (a) you're extracting a shared library used by both a Symfony and a Laravel service, or (b) you genuinely want the bundle's specific wrapper behavior. Otherwise, the honest first move is to skip it.

Implementation Patterns

Symfony-native usage (the pattern the bundle is built for):

• Constructor injection of the client service or its interface. Prefer injecting an interface if the bundle defines one — it makes swapping a decorator or test double trivial.
• Config-driven base URI and default headers. Put the base URL in config/packages/weblabel_http_client.yaml and vary it per environment via .env interpolation rather than hardcoding. This is the single biggest win of using a bundle over new Client().
• Autowiring aliases. If the bundle exposes a concrete class but you want an interface, add an alias in config/services.yaml:

  Weblabel\HttpClientBundle\Contract\ClientInterface:
      alias: weblabel.http_client
  

  Check the exact service ID in the extension class first — guessing IDs is the #1 source of ServiceNotFoundException.

Decorator pattern for cross-cutting concerns. Because the bundle is thin, wrap its client in your own class implementing the same interface and add logging, retries, or circuit-breaking there. This keeps the vendor surface area small and is easier to test than monkey-patching config.

Bridge pattern for Laravel. If you must use it:

1. Add a small service provider that binds the bundle's client class into Laravel's container, constructing it manually from config('services.weblabel.*').
2. Bind your own WeblabelClientInterface and inject that into jobs/controllers — never inject the vendor class directly.
3. Isolate it in one adapter class so a future migration to Http:: is a one-file change.

Testing. In Symfony, mock the underlying transport (Symfony HttpClient's MockHttpClient or a PSR-18 mock) rather than the wrapper. In Laravel, if you're bridging, use Http::fake() only if the bundle ultimately routes through Guzzle/Symfony HttpClient — verify this first. Otherwise, bind a fake implementation of your adapter interface.

Job/queue integration tip: for Laravel queues, always set explicit timeouts on the injected client and wrap calls in try/catch that translates transport exceptions into your domain exceptions. The bundle does not appear to impose sane defaults.

Gotchas and Tips

• Framework mismatch is the headline gotcha. No Laravel auto-discovery, no facade, no config publishing. Any usage in Laravel is manual container wiring and manual config loading. Budget time for this and document it.
• Unmaintained since December 2021, zero stars, zero dependents. This is effectively an unvetted, single-maintainer package. Before shipping it, read every source file, pin the version exactly, and vendor the code if it's load-bearing. Do not assume security patches will arrive.
• Compatibility risk. A 2021 Symfony bundle will have constraints on symfony/framework-bundle and symfony/http-client that may conflict with modern Symfony or with PHP 8.2+. Run composer why-not early; expect to fork or shim.
• Config key names are not documented reliably. Configuration.php is the source of truth. Symfony will silently ignore typo'd keys in some legacy extension setups — enable framework.php_errors and check the container with bin/console debug:config weblabel_http_client.
• Know what's underneath. Is it Symfony HttpClient, Guzzle, or raw cURL? Error behavior differs: Symfony HttpClient throws on 4xx/5xx by default ($client->request(...)->getContent() throws), whereas Guzzle needs http_errors => false to return status codes. Mismatched expectations here cause silent production bugs.
• Timeout and retry are almost certainly not configured for you. Set them explicitly at the config layer or in a decorator. A zero-config HTTP call in a queue worker is a denial-of-service waiting to happen.
• Debugging. The Symfony profiler's HttpClient panel only populates if traffic flows through Symfony HttpClient — if the bundle wraps something else, you lose that visibility. Add PSR-3 logging in a decorator regardless of framework; it's the most reliable debugging surface.
• Extension points to look for: event subscribers, a client factory, and the service definitions themselves. If the bundle offers none, prefer composition (your own client class holding the vendor one) over forking — forks of abandoned packages rot fastest.
• Migration path in Laravel: if this was introduced for a specific integration, the exit strategy is a single adapter class whose body swaps from the bundle call to Http::withToken(...)->baseUrl(...)->timeout(...)->retry(...)->get(...). Design for that swap from day one.