Http Transport Laravel Package

Product Decisions This Supports

• Build vs. buy on the outbound HTTP layer. Every product that talks to third parties eventually decides: call Illuminate\Support\Facades\Http / Guzzle directly from feature code, or own a thin transport port. This package is a worked example of the second option — a request/response interface plus composable decorators — so it lets us price that decision instead of debating it abstractly.
• Portability and exit strategy. If the roadmap includes self-hosted/on-prem deployments, shared packages used by workers or non-Laravel services, or a possible framework migration, a transport contract that isn't welded to the Laravel container protects that option. The package itself is framework-agnostic; that property is the product decision, not the code.
• Reliability as a product feature. Retry/backoff, timeout, and failure-normalization policy for payments, KYC, shipping, or LLM providers is usually scattered across try/catch blocks per integration. A decorator-based transport makes "how many retries, what timeout, what the user sees on failure" a reviewable, unit-testable policy — which is a product decision about degraded-mode UX, not just an engineering one.
• Client-swap decisiveness. Choosing between cURL, Guzzle, and Symfony HttpClient can be deferred if call sites depend on an interface. Useful when security or procurement asks "what happens if we drop vendor X?"
• Test strategy. Fake/in-memory transports let the suite exercise failure paths deterministically and keep CI off the network. That's a decision about how much of the test suite is allowed to be flaky.
• Roadmap de-risking for multi-provider surfaces. Worth a timeboxed spike when a second payment/messaging/identity provider is coming, where abstraction cost amortizes across 3+ integrations. Not worth it for a single call site.
• Honest counterweight: 1 star, 0 dependents, and a single-maintainer release cadence mean this is not a "buy" decision with community validation. The realistic decision it supports is "borrow the design," or "adopt with a fork-and-own plan."

When to Consider This Package

Consider it when:

• The team is comfortable with functional/immutable PHP and PSR-7 request/response objects, and accepts manual wiring in our own service provider (no facade, no auto-discovery, no published config).
• We have — or are about to have — three or more outbound integrations, so a shared transport layer pays for itself.
• We need uniform, testable policy: retries, exponential backoff, timeouts, request signing, logging, failure mapping.
• We need framework independence: the same integration code runs in the Laravel app, queue workers, and a non-Laravel service, or survives a framework change.
• We are willing to pin a version, read the (small) source, and accept ownership of a fork if upstream stalls.

Look elsewhere when:

• The need is "call one API from one controller." Use Laravel's Http client; it's already installed, documented, and known by the team.
• We need a full-featured client: PSR-18/PSR-17 discovery, connection pooling, HTTP/2, async/concurrency, cookie jars, OpenTelemetry hooks, a broad middleware ecosystem. This is an abstraction over transports, not a batteries-included client — Guzzle and Symfony HttpClient carry the ecosystem and security-review history.
• Security/procurement requires SCA maturity, CVE history, or vendor support. Zero dependents and one star will not clear that bar, and the review cost lands on us.
• The team won't adopt functional style. The impedance mismatch will cost more than the abstraction saves.
• We expect a maintained Laravel integration — container bindings, config publishing, Octane/queue compatibility. That's our build either way.

How to Pitch It (Stakeholders)

Executives. We're evaluating a small MIT-licensed PHP abstraction for outbound HTTP calls. It ships no user-facing feature; it reduces the cost and risk of the integrations we already run and the ones on the roadmap — fewer bespoke retry implementations, fewer provider-specific failure paths, cheaper provider swaps. Framing: this is a design pattern we can adopt for free, not a vendor commitment. Recommendation is a two-day spike inside one integration, not a platform mandate. The project has negligible community adoption (1 star, 0 dependents), so the real cost is our own maintenance; we should only take it on with a fork-and-own plan and at least three integrations to amortize it.

Engineering. The value is policy-as-code for HTTP — retries, backoff, timeouts, failure normalization, and a seam for swapping clients — behind a request/response contract that isn't Laravel-shaped. The cost is real: manual container wiring, functional/immutable style, PSR-7 plumbing, and no upstream safety net. Proposal: wrap it behind an internal Transport port so feature code never imports the package directly. That keeps the exit cheap and lets us fall back to Guzzle or Symfony later without touching call sites. Success test for the spike: if the decorators don't save roughly two days of our own glue over the next quarter, we keep Illuminate\Support\Facades\Http and take only the interface idea.

One-line message: borrow the architecture, buy the client, and adopt the package only if we're prepared to own it.