Http Laravel Package

Product Decisions This Supports

• Standardizing the HTTP boundary in your codebase. PSR-7 (psr/http-message) defines immutable request/response/value-object interfaces. Adopting a PSR-7 implementation lets you write domain and integration code against interfaces instead of a concrete client — the decision that actually matters here is "interface vs. vendor SDK," not "which wrapper library."
• Framework-agnostic clients and SDKs. If you ship a PHP SDK, webhook receiver, or internal service client that must run inside Laravel and in a queue worker, CLI tool, or non-Laravel service, PSR-7 messages are the portable currency. This package supports that use case in principle.
• Roadmap: decoupling transport from application code. A PSR-7 seam is a prerequisite for later swaps (Guzzle → Symfony HttpClient, or adding PSR-18 discovery), for adding a shared middleware pipeline (retries, correlation IDs, auth signing, structured logging), and for replaying/mocking traffic in tests via a handler stack.
• Build vs. buy vs. already-have. This is the critical PM framing: Laravel already ships an HTTP client on top of Guzzle, and Guzzle ships its own actively maintained PSR-7 implementation (guzzlehttp/psr7). swlib/http therefore competes with a component you already have, not with a build-from-scratch effort. Its stated value ("PSR-7 implementation, thanks to Guzzle") is a thin re-wrap of a dependency you get for free.
• Use cases it would nominally unlock: typed request/response objects for partner APIs, response-stream handling (large downloads, CSV imports), middleware for observability and rate limiting, and test doubles with a mock handler. All of these are achievable with the packaged Guzzle stack without adding this dependency.
• Decisions it should not drive: picking a primary HTTP transport, defining your API client architecture, or gating a Laravel upgrade on this library.

When to Consider This Package

Consider it only when:

• It is already in your composer.lock — i.e., you inherited it via a transitive or legacy dependency and need to understand and plan around it, not introduce it.
• You need a minimal PSR-7 message implementation with no framework coupling, and a spike/prototype tolerates an unmaintained, low-traffic dependency.
• You have a frozen, low-risk surface — internal, non-internet-facing tooling where a stale dependency cannot become a security or upgrade blocker.

Look elsewhere by default. Signals against adoption:

• Maintenance risk. Last release 2020-08-15 — no patches for roughly four to five years. No evidence of PHP 8.x compatibility work, which is disqualifying for Laravel 10/11 projects (PHP 8.1+).
• Supply-chain opacity. The repository is listed as unknown; 11 stars; effectively a bus factor of one. You cannot assess commit history, issue responsiveness, or release provenance — a hard blocker for any dependency going through a security or compliance review.
• No differentiation. PSR-7 is a published specification with multiple mature implementations (guzzlehttp/psr7, nyholm/psr7, laminas/laminas-diactoros). Choosing the least-maintained one buys you nothing.
• Redundancy with the Laravel baseline. You would be adding a dependency to obtain behavior your framework already provides.

Due diligence checklist if it is proposed: who owns it, where the canonical repo lives, PHP 8.1→8.4 compatibility, CVE/security-advisory pipeline, transitive dependency graph, and a written exit plan. Absent satisfactory answers, the recommendation is to standardize on guzzlehttp/psr7 behind the psr/http-message interfaces and avoid a hard dependency on this package.

How to Pitch It (Stakeholders)

For executives (one paragraph): swlib/http is a small, MIT-licensed PHP library that implements an industry-standard HTTP interface. It is free to use, but it has had no release since August 2020, has negligible community adoption, and its source repository cannot be verified. That combination means we would own the maintenance of a component we do not need: our framework already provides equivalent, actively maintained functionality at no cost. My recommendation is not to adopt it as a dependency; where it already exists, treat it as technical debt with a scheduled removal. The business case is straightforward — the licensing cost is zero, but the ongoing maintenance, upgrade-friction, and security-review costs are non-trivial and entirely avoidable.

For engineering (summary): Write against the PSR-7 interfaces (psr/http-message), not against a concrete library. The specification is stable and its implementations are interchangeable, so the interface choice is the durable architectural decision and the implementation is a one-line swap. Back that interface with guzzlehttp/psr7, which is what Laravel and Guzzle already pull in, is actively maintained, and supports current PHP versions. Keep your HTTP clients behind your own thin abstraction (a small client interface plus a handler/middleware stack) so retries, correlation IDs, auth signing, and test doubles are composed rather than inherited from a vendor. Migration cost away from swlib/http is bounded precisely because the contract is a standard: replace the message factory and keep the call sites. If the package is currently in the lockfile, add a ticket to remove it during the next dependency-refresh cycle rather than bundling it into feature work.