Http Client Bundle Laravel Package

Getting Started

What this release is. tourze/http-client-bundle moved from 1.0.1 to 1.1.0. The published notes contain only a GitHub compare link, so the surface area of the change is unenumerated — but the version bump is a minor bump, which under semver means additive features and no removals. Treat 1.1.0 as a drop-in upgrade from 1.0.x and read the diff at the compare URL before relying on anything new.

First steps:

1. composer require tourze/http-client-bundle:^1.1 (or composer update tourze/http-client-bundle if already installed).
2. Open the compare page from the release notes and scan src/ for new classes/interfaces — that is the fastest way to discover what 1.1.0 actually added, since the notes don't say.
3. Register the bundle/service provider as documented in the package README. For a Symfony-style bundle consumed in Laravel, this is typically an auto-discovered service provider; if not, add it to bootstrap/providers.php.
4. Smoke-test with an outbound call to a staging endpoint before wiring it into anything critical.

First use case: replace ad-hoc Http::get() calls in a single service class with the bundle's client so you get one place to configure base URI, timeouts, retries, and auth headers. Do this on one integration first — do not refactor every HTTP call site at once on a minor bump you can't fully read from the notes.

Implementation Patterns

Wrap it behind your own interface. The bundle is a transport concern. Inject the bundle's client into a small domain-specific class (AcmeApiClient) and have application code depend on that, not on the bundle. This is the single highest-leverage pattern here: it means the next opaque minor release can be absorbed by editing one file instead of grepping for call sites.

final class AcmeApiClient
{
    public function __construct(private readonly HttpClientInterface $http) {}

    public function findOrder(string $id): array
    {
        return $this->http->request('GET', "/orders/{$id}")->toArray();
    }
}

Centralise configuration. Keep base URI, default headers, and timeout in config/services.php or a dedicated config/http_client.php, and let the container build the client. Per-call overrides should be the exception, not the rule — otherwise a timeout change becomes a code change.

Testing. In tests, bind a fake/mock implementation of the interface you injected rather than hitting the network. If the bundle exposes Laravel's Http facade under the hood, Http::fake() works as usual; if it wraps Symfony's HttpClientInterface, use a MockHttpClient. Confirm which by inspecting the constructor signature — this determines your entire test strategy.

Retries and idempotency. Configure retries at the client level for idempotent verbs only (GET/PUT/DELETE). Never blanket-retry POSTs to payment or order-creation endpoints; a 1.1.0 retry feature (if added) is exactly the kind of thing that turns a transient timeout into a duplicate charge.

Integration tip: run the upgrade branch through your existing integration test suite against a real staging endpoint once, manually. Minor bumps in HTTP-layer packages frequently change default header handling or timeout semantics without breaking type signatures.

Gotchas and Tips

• The changelog is a link, not a changelog. Do not treat "minor bump" as a guarantee. Open the compare diff, and if the maintainer keeps no CHANGELOG.md, pin to 1.1.* and read the diff on every bump. Consider filing an issue requesting structured release notes — you are currently paying the cost of reverse-engineering each release.
• Symfony bundle in a Laravel app. tourze packages are typically Symfony bundles. If so, expect friction: service definitions in YAML/XML, Symfony-style tags, and possibly a PSR-18/HttpClientInterface contract rather than Laravel's Illuminate\Http\Client\Factory. Check the constructor argument types before assuming Http:: semantics — ->toArray(), exception types, and status-code handling differ between the two.
• Exception model. Symfony HttpClient throws on 4xx/5xx only when configured to (throw option / getContent(false)); Laravel throws RequestException by default. A silent behavioural difference here is the classic post-upgrade bug: code that previously got an exception now gets a response object with a 500 body, and downstream parsing fails confusingly.
• Timeouts are not retries. Set an explicit timeout (and a connect timeout) on every client. Defaults in HTTP bundles are frequently "no timeout", which manifests as workers hanging until max_execution_time.
• Debugging. Log the request ID and the resolved base URI once at boot in local/staging — misconfigured base URIs are the number one cause of "it works locally" in HTTP client wrappers. If the bundle supports a profiler/decorator, enable it in local only.
• Extension points. Prefer decorating the injected interface over subclassing the bundle's concrete client. Decorators survive minor releases; subclassed concrete classes break the moment a constructor argument is added.
• Lock file discipline. Commit composer.lock immediately after the upgrade and let CI install from it. Because you can't enumerate the changes, reproducibility is your safety net.