Rest Client Laravel Package

Product Decisions This Supports

• Build vs. buy for the HTTP integration layer. This package is a reference architecture, not a dependency. Reading its source (lazy request objects, PSR-18 client abstraction, promise-based async, immutable request/response value objects) is useful input to a design doc when deciding whether to wrap Laravel's Http facade, adopt Saloon, or hand-roll a domain-specific client.
• API client architecture review. It is a worked example of the port/adapter split for outbound HTTP: transport swapped behind an interface, requests as composable values rather than imperative calls. That pattern directly informs decisions about how to make third-party integrations testable without Http::fake() everywhere.
• Async/batching roadmap items. If the roadmap includes fan-out calls (enrichment, multi-vendor aggregation, webhook dispatch), the promise-chaining model here is a concrete precedent for what a non-blocking client looks like in plain PHP — useful when scoping whether async is worth the complexity versus queued jobs.
• Vendor risk calibration. A 2-star, archived, zero-dependent package is a data point for how thin the long tail of PHP HTTP clients is. It supports the standing rule: HTTP transport is a "buy/standardize" category, not a "shop the ecosystem" category.
• Explicitly not a feature decision. No Laravel service provider, no config publishing, no facade, no retry/backoff middleware, no logging hooks into Laravel's channels. Any use requires an integration layer you own — so it cannot be a line item that ships a feature.

When to Consider This Package

Consider only in these narrow cases:

• As a design reference, not a dependency — you are writing an internal HTTP client abstraction and want a compact example of a PSR-18/PSR-7 client with promise support and immutable request composition.
• You are already inside the Innmind ecosystem (functional PHP, its http/http-client abstractions), where API conventions and version alignment already exist.
• You are prepared to vendor or fork. Archived status means you own maintenance: security patches, PSR version bumps, PHP minor-version compatibility, and any bug you hit. Budget for that explicitly before adoption, and record it as technical debt with an owner.
• Constraint profile matches: small surface area, no framework coupling, no transitive dependency sprawl, and you accept the learning curve of its functional style.

Look elsewhere when:

• You are building in Laravel and want speed. Use the built-in Http client (Guzzle-backed) for synchronous work and Http::pool()/queues for concurrency; use Saloon when you need structured, testable, per-service connectors with auth, retries, and record/replay testing.
• You need operational features — retries with backoff, circuit breaking, rate limiting, structured logging, OpenTelemetry tracing, or Laravel-level observability. None ship here; you would build them.
• Team familiarity matters. Immutable/functional idioms and promises raise the floor for mid-level contributors; the maintenance cost usually exceeds the benefit for a two-star unmaintained library.
• You need a support contract or CVE response. Archived projects do not provide it. For anything customer-facing or payment-adjacent, this is disqualifying.

How to Pitch It (Stakeholders)

To executives: This is not a vendor we should adopt. It is a small, archived, MIT-licensed PHP library with negligible adoption, and I am recommending we use it only as a reading reference — roughly half a day of engineering time — to sanity-check the design of our outbound API layer. Cost is near zero; the value is avoiding a bespoke HTTP abstraction that we would regret. No new dependency enters the supply chain, no procurement, no ongoing licence cost.

To engineering: Treat innmind/rest-client as a pattern source, not a package. What is worth stealing: requests modeled as lazy, composable values; the transport behind a PSR-18-style interface so tests substitute a fake without touching the framework; and promise-based chaining as a model for fan-out calls. What is not worth taking: the dependency itself — archived, two stars, no dependents, no Laravel integration, no retry or logging middleware, and an unfamiliar functional API that would slow onboarding. Our default remains Laravel's Http client, with Saloon for connector-shaped integrations. If someone wants to prototype the async fan-out path against this code, that is a timeboxed spike, not a branch.

To the security and platform reviewer: No adoption proposed. Flagging it here only so the evaluation is on record: archived upstream, single maintainer history, no CVE process, no PHP-version support commitment. We are deliberately not adding it to the dependency inventory.

The ask: approve a short design-review spike to extract the interface pattern, and confirm the standing decision that HTTP transport in this codebase is standardized on Laravel Http (sync) plus queued jobs or Http::pool (concurrency), with Saloon as the escape hatch for complex third-party connectors.