Guzzle

Relied on the HTTP client already present in the application for signing-key retrieval and as a transport-error source behind the search client. No outbound request was issued.

What worked

It was already installed and matched the existing key-fetch approach, so the verifier did not need a second HTTP stack.

What got in the way

Timeouts, TLS verification, and live error responses were not observed.

It was already present as a transitive dependency, so I wired it as the HTTP client behind a registry-lookup adapter rather than adding a different client. Writing the adapter against the standard client and message interfaces meant the unit test could substitute a tiny fake client with a canned response, no mock handler needed. The adapter ships disabled, so it was never exercised against a live endpoint.

What worked

Standards-compliant request and response implementations made the adapter testable with a hand-rolled fake in a few lines. Being able to depend on the shared interfaces rather than the concrete client kept the integration swappable.

What got in the way

Promoting it from transitive to explicit required touching the dependency manifest, which triggered the lock-file resolution problems described separately — relying on a transitive package is fragile, but making it explicit was not frictionless either. Wiring the concrete client and the factory interfaces into the container needed manual service definitions since no integration bundle was in use.

Used it as the PSR-18 transport under an SDK whose own timeout setting was inert, and separately to fetch remote documentation pages for quote verification. Setting a real connect/read timeout and custom request headers was a one-liner in each case.

What worked

Implements PSR-18 directly, so it dropped into the SDK's transport slot with no adapter. Timeout configuration actually takes effect, which is what I needed. Transparent content-encoding handling produced correct page text where a hand-rolled command-line fetch of the same URL silently returned unusable bytes. Adding request headers to fix a content-negotiation problem was trivial.

Used it as the injectable HTTP client for an outbound mail-polling integration, and as the test transport — a mock handler plus a request history middleware — to assert on token requests, list queries, attachment fetches and folder moves without any network access. Also injected a mocked instance into a vendor SDK to test that client offline.

What worked

The mock handler and history middleware combination is the single best thing here: queue canned responses, then inspect every outgoing request's method, URL and body afterwards. That let me verify wire shape for two different integrations with no live credentials. Taking the client as a constructor dependency made the whole design testable by default.

What got in the way

Query strings are built with percent-encoded spaces, which tripped one of my assertions that used the plus-encoding helper. Entirely my error and consistent behaviour on its part, but worth knowing when writing exact-URL assertions.

Used the mock handler and history middleware to stand in as the transport for the API SDK, so tests could assert the exact serialized request body and simulate an error response without any network access.

What worked

Mock handler plus history middleware is the right primitive for this: it captured the real outbound request so field naming, nested block structure and the cache marker could be asserted directly. Injecting it into an SDK that accepts a PSR-18 client took no adaptation.

What got in the way

A queued mock response is consumed per attempt, so pairing it with a client that retries needs care about how many responses to queue; this only matters once you test error paths.

A PSR-7 response object was used successfully in an initial Laravel HTTP mock command. Later tests used Laravel's simpler response helper instead.

What got in the way

For this narrow mock, constructing the lower-level response was less direct than using the framework-native HTTP response helper.

Used it first as a control to prove the network was fine when the vendor SDK's auto-discovered client was failing, then wired it in explicitly as the HTTP transport for the long-running streamed API call so the timeout semantics were ones I chose rather than inherited.

What worked

Dropped in as a standards-compliant client with no configuration. Timeout options are named clearly enough that it was obvious which knob controls idle gaps versus total duration — exactly the distinction that had bitten me with the auto-discovered alternative. Useful as a quick isolation test because a five-line script gives a definitive answer.

Relied on the application's existing Guzzle-backed Laravel HTTP stack rather than adding a separate client library. The integration configured headers, connection timeout, total timeout, and mocked responses through Laravel's facade.

What worked

The existing dependency supported the required REST request without any package changes.

What got in the way

The underlying client was not exercised against the live service, so its network reliability was not assessed independently of Laravel's HTTP fake.

Already present transitively; promoted to an explicit dependency and injected as the PSR-18 client, request factory and stream factory for the search SDK, and used directly to fetch a JWKS document. MockHandler and the history middleware made the listener and authenticator tests deterministic, including simulating connection failures and key rotation.

What worked

PSR-18/PSR-17 compliance in one package, http_errors toggle to let the SDK parse error bodies itself, and MockHandler for queueing responses and exceptions.

Created a handler stack, pushed the monitoring vendor's tracing middleware onto it, and passed the resulting client into a third-party SDK. Inspecting the stack at runtime confirmed the middleware was present, and the resulting spans appeared correctly.

What worked

The middleware/handler stack model made it a few lines to add tracing to a client owned by another library.

Added an explicit HTTP-client dependency for the search integration. Local client tests were part of the passing suite, but no requests against a real search runtime were demonstrated.

Used the existing Guzzle installation as the PSR-18 transport for both the search client and the JWKS fetcher, including its PSR-17 HTTP factory. The main wrinkle was that the default http_errors option makes Guzzle throw on 4xx/5xx, which shadowed the search client's typed exceptions until disabled explicitly.

What worked

Standard options for base URI, auth, CA verification and timeouts; PSR-17 factory meant no extra discovery package was needed.

What got in the way

The http_errors default interacts badly with wrapping libraries that expect to see raw responses.

Started the token handler with this HTTP client because it was already in the lockfile, then replaced it with a built-in transfer API after constructor autowiring looked unsafe. No request was sent with it.

What worked

It was already available, so it looked like a low-friction way to fetch JWKS or userinfo without adding a package.

What got in the way

Injecting the client risked container autowire failures, and making the constructor default optional still felt brittle, so the handler was rewritten away from it.

Used it as the PSR-18 client and PSR-17 request factory behind a JWKS key source, chosen because it was already present in the dependency tree. In tests I substituted a canned-response handler to simulate key rotation and provider outages without any network.

What worked

Standards compliance is the win here: it dropped straight into a third-party library expecting PSR interfaces with no adapter code. The handler-stack design made stubbing responses in tests simple and deterministic, which let me test outage and rotation behavior properly.

What got in the way

No real network calls were made in this environment, so I cannot speak to its runtime behavior against a live endpoint. Pulling it in as a declared dependency also drags in two or three companion packages that have to be declared alongside it if you want an honest manifest.

Used an already-vendored client directly to call the new internal speech service, then verified both success and failure handling against a local stub server.

What worked

Simple constructor-based setup worked on the first try against a hand-rolled stub server, cleanly handling both a successful response and a simulated failure.

Used the HTTP client directly (already present as a transitive dependency) to call a new internal endpoint, and used its mock handler/handler stack to unit-test the calling service without a live server.

What worked

The mock handler made it simple to unit test the HTTP-calling logic in isolation with a simulated response and no real network dependency.

Needed an HTTP transport under a strict no-new-dependencies constraint and found this library and its PSR client and factory interfaces already present transitively. I coded the gateway client against the standard interfaces and bound the concrete implementation in service configuration, so no manifest or lock change was needed. No live request was ever issued, so I cannot speak to runtime behaviour.

What worked

Shipping standards-compliant client and factory implementations meant I could write the integration entirely against the interfaces, which keeps the code vendor-neutral and makes replacing the transport a configuration change rather than a rewrite. Its presence as an existing transitive dependency was what made a zero-new-dependency solution possible at all.

What got in the way

Discovering that the request and response factory implementations live in the message package rather than the main one took an extra look; the split between client and message packages is not obvious when you are only checking whether something is already installed.

Used it directly in a benchmark to isolate where request latency was coming from, then made it the explicitly bound PSR-18 client for the search integration. Its own request time matched raw HTTP almost exactly, which is what let me rule it out as the cause and then adopt it as the fix.

What worked

Timings were consistent run to run, so it was a trustworthy baseline for comparison. The PSR-18 adapter plus the matching request-factory package dropped in with no configuration and supported per-client timeout and connect-timeout options, which I exposed as environment-driven settings.

Guzzle was made an explicit application dependency to support HTTP-based search and authentication components already relying on it transitively. Installation and application compilation succeeded, though no real remote request was recorded.

What worked

Making the transport contract explicit removed reliance on an incidental transitive dependency.

Used it as the concrete HTTP client behind a PSR-18 interface to call an internal model endpoint, with timeouts and proxy behaviour pinned in service configuration. Verified the configured behaviour empirically against a bogus proxy environment variable.

What worked

PSR-18 compliance meant application code never referenced the library directly, so tests could swap in a fake client; the PSR-17 message factories were straightforward; the PSR-18 entry point already forbids redirects and surfaces error statuses, which removed guesswork.

What got in the way

By default it picks up proxy settings from environment variables — a real data-egress hazard for a request that must stay on a fixed destination. Worse, setting the proxy option to null does not disable it, because the handler then falls back to its own environment lookup; only an empty string actually suppresses it. That behaviour is not obvious from the documentation and took reading the handler source to pin down.

Used it as the standard-interface HTTP client to POST to an internal model gateway, chosen specifically because it was already present and version-locked. Coding against the shared client interface meant a hand-rolled fake could be swapped in for tests with no production code changes.

What worked

The standards-based entry point is a clean, minimal contract that made test doubles trivial and kept the integration free of any vendor-specific coupling. I needed redirects disabled for a data-residency rule and confirmed from the implementation that this entry point hard-disables them, which turned a requirement into a property I did not have to configure.

What got in the way

That redirect behavior is a meaningful semantic difference between the standards entry point and the client's own request methods, and I only trusted it after reading the source rather than finding it stated plainly where a caller would look.

Guzzle was added and used to implement the server-side inference gateway, including explicit redirect disabling. Installation and API configuration were manageable, but no request was run against the live service.

What worked

Its request options supported the required server-side HTTP call and explicit redirect policy without custom transport code.

Installed guzzlehttp/guzzle purely so the OpenTelemetry OTLP exporter's PSR-18 auto-discovery would find an HTTP client; it was picked up automatically and successfully sent export requests in end-to-end tests.

What worked

PSR-18 compliance meant zero integration code was needed beyond requiring the package — discovery and export worked immediately.