Http Laravel Package

Product Decisions This Supports

• Build vs. buy/borrow for HTTP plumbing (recommendation: neither — this is a “skip”): The package overlaps almost entirely with capabilities Laravel already ships (Illuminate\Support\Facades\Http, Guzzle) and with any PSR-18 client + PSR-7 implementation. It does not unlock a capability we lack; it only offers a slightly friendlier header/query-string ergonomic layer.
• Dependency risk triage: The repo is archived and its last release was 2016-09-20. That predates PHP 7.1, modern PSR-7/PSR-18 tooling, and every currently supported Laravel version. Its low composite score (0.10) with only 17 stars confirms it is not a maintained or community-backed option. Treat it as a known-abandoned artifact, not a candidate.
• Roadmap impact: Zero. Adopting it would create a migration project later (PSR-7 bridges, symfony/psr-http-message-bridge, potential PHP 8.x incompatibilities) without delivering differentiated value now.
• Use-case fit check: The two legitimate use cases — (a) sending outbound HTTP calls, (b) normalizing inbound request/header/query handling — are both already covered by first-party Laravel APIs. There is no product problem here that a package decision solves.
• Ecosystem/compliance decision: An archived dependency with no security response process is a supply-chain liability. If it lands in a codebase, it becomes a recurring item in dependency audits and an unpatched CVE surface with no upstream to fix it.
• PM-level call: Do not add. If already present in a legacy service, scope a low-priority replacement (Guzzle or Laravel’s HTTP client for outbound; nyholm/psr7 + laminas-diactoros if PSR-7 value objects are genuinely needed) rather than an upgrade.

When to Consider This Package

Adopt only if all of the following are true — which is realistically never for new work:

• You are maintaining a PHP 5.x/7.0-era application already pinned to this dependency, and the cost of removal exceeds the cost of carrying it short-term.
• The codebase already depends on its specific Request/Response/Header classes in many call sites, making a swap a non-trivial refactor.
• You have accepted the risk explicitly: no upstream fixes, no security patches, no PHP 8+ guarantee, and a documented internal fork/owner if it breaks.

Look elsewhere in essentially every other case:

• Any new greenfield or actively developed Laravel app → use the built-in Http facade (outbound) and Laravel’s request/header helpers (inbound). Nothing to install.
• You need PSR-7/PSR-18 interoperability (middleware stacks, third-party SDKs) → use a maintained implementation: nyholm/psr7, laminas/laminas-diactoros, guzzlehttp/guzzle (PSR-18 client), plus symfony/psr-http-message-bridge for Laravel.
• You need retries, timeouts, concurrency/pooling, testing fakes, or telemetry → Guzzle or Laravel’s HTTP client; this package offers none of that depth.
• You have a security review or SOC2/ISO dependency policy → an archived package with a 2016 last release will fail the gate; don’t spend cycles proposing an exception.
• You want “minimal dependencies and small footprint” → verify against the actual alternative: Laravel’s HTTP client is already installed, and nyholm/psr7 is tiny and actively maintained. “Small” is not a differentiator when the maintained option is free and already present.

How to Pitch It (Stakeholders)

For executives (one line): We evaluated wandu/http and recommend not adopting it — it is an archived, unmaintained 2016-era HTTP helper whose functionality Laravel already provides for free, so adding it would introduce dependency and security risk with no product benefit.

For engineering leadership: This is a small, framework-agnostic convenience layer over requests, responses, and headers. It is PSR-friendly but predates PSR-18 and modern PHP, has 17 stars, no release since September 2016, and the repository is archived — meaning no bug fixes and no security response. Laravel’s Http facade covers outbound calls; request/header/query handling is native. Where PSR-7 interop is genuinely required, nyholm/psr7 + symfony/psr-http-message-bridge is the maintained path.

Ask: No engineering investment. If the package already exists in a service, log it as technical debt with a low-priority replacement ticket; do not add it to any new or in-flight work. Revisit only if a legacy system proves it cannot be removed cheaply — and even then, timebox the fork/maintain decision with a named owner.