Http Laravel Package

Product Decisions This Supports

• Dependency policy / supply-chain hygiene: this is a clean "no" that lets you codify a rule — no archived, unmaintained packages with zero downstream dependents in the request/response path. Worth recording as a precedent so future evaluations move faster.
• Build vs. buy vs. use-what's-already-there: the decision resolves to use what's already there. Laravel ships Illuminate\Support\Facades\Http (Guzzle-backed) for outbound calls and Illuminate\Http\Request/Response for inbound. Any HTTP abstraction need in a Laravel app is already satisfied by first-party code.
• Architecture standardization: if a proposal surfaces to introduce a third-party HTTP abstraction layer (PSR-7 bridge, custom client, URL value objects), the correct target is PSR-7/PSR-18 (nyholm/psr7, guzzlehttp/guzzle) or symfony/http-foundation — not a project-local dialect with its own autoloader and stream primitives. This package is useful mainly as a foil for that argument.
• Roadmap impact: none. There is no feature, launch, or migration that should be sequenced around this package.
• Legacy triage: the one scenario with real decision value — if a codebase audit turns up hoa/* imports, that becomes a remediation ticket (replace with Guzzle/PSR-7, retest, remove the custom autoloader bootstrap), not an integration task.
• Not supported: API client design, SDK selection, webhook handling, or URL routing decisions. The library's abstractions are conceptually present but not composable with Laravel's container, middleware, or testing helpers.

When to Consider This Package

Adoption criteria — all would have to be true, and realistically they can't be met:

• You are maintaining a pre-existing application already built on the Hoa stack (Hoa\Core bootstrap, Hoa\Stream, Hoa\Protocol) and need to keep a working HTTP layer in place while planning its removal.
• You need a read-only reference for how stream-backed HTTP and URL parsing were modeled circa 2015 — useful for design archaeology, not for production code.

Look elsewhere when — i.e., essentially always in a Laravel context:

• Archived status (since ~2017, last release 2017-01-13). No security patches, no PHP 8.x compatibility work, no maintenance. Unacceptable in anything handling user traffic or credentials.
• Zero dependents. No ecosystem pressure to keep it working, no community fixes, no Stack Overflow surface. Support cost lands entirely on your team.
• Non-standard autoloading and runtime. Hoa packages historically ship their own autoloader/bootstrap conventions that collide with Composer-first Laravel apps and complicate Laravel's service container, facade, and testing ergonomics.
• Not PSR-7 / PSR-18. You'd be writing adapters to talk to Guzzle, Laravel's HTTP client, or any middleware — net new glue code with no upside.
• Star count (10) and opportunity score (19.9). Signal of abandonment, not of a niche gem. There is no maintainer relationship to build.
• Preferred alternatives: guzzlehttp/guzzle (and Laravel's Http facade on top of it), symfony/http-foundation, nyholm/psr7 + laminas/laminas-diactoros, symfony/http-client for PSR-18.

Verdict: reject. Do not add to composer.json. If found as a transitive or legacy dependency, treat it as technical debt with a removal plan.

How to Pitch It (Stakeholders)

One line: We evaluated hoa/http and are not adopting it — it's archived, unmaintained since 2017, has no downstream users, and duplicates HTTP capability Laravel already provides for free.

For executives: adopting it would add a permanent maintenance liability in the most security-sensitive part of the stack (the network boundary) in exchange for zero functional gain. Our current stack — Laravel's built-in HTTP client for outbound calls and Symfony HttpFoundation for inbound — already covers every requirement, is actively patched, and is supported by a large vendor and community. Recommendation: no action beyond recording the rejection; if any hoa/* code exists in our repos, open a remediation ticket.

For engineering: the package predates PSR-7/PSR-18, ships its own autoloader and stream primitives, and has no PHP 8 compatibility commitment. Integrating it means writing adapters, pinning an unsupported PHP range, and owning the CVE surface ourselves. Use Illuminate\Support\Facades\Http / Guzzle for clients and PSR-7 implementations where an interchange format is genuinely needed. Cost of adoption: days of glue work plus indefinite maintenance. Cost of the alternative: zero — it's already installed.