Zttp Laravel Package

Product Decisions This Supports

• Build vs. buy for the "HTTP client" layer. Zttp is a thin, MIT-licensed wrapper over Guzzle, so the real decision is not whether to build an HTTP abstraction (worth building, cheaply) but whether to own it or take a dependency. Zttp argues for dependency: readable get/post, withHeaders, withToken, withBasicAuth, asJson, asFormParams, timeout, retry — a scope small enough to audit in an afternoon, large enough to save a sprint.
• Standardizing outbound integration code. If the roadmap has several third-party API integrations or partner webhooks, Zttp is a cheap way to make every call site look the same: readable, reviewable, and short. The ZttpResponse accessor pattern is the real product value — it removes repeated response-parsing code across features.
• Delivery speed on integration-heavy epics. Concise chainable helpers translate directly to less boilerplate per integration, which is measurable in cycle time for "connect to vendor X" stories. This is an estimate to validate, not a given.
• Roadmap framing: adopt the pattern, not the artifact. Zttp's ideas were absorbed into the framework itself (Laravel's HTTP client, Laravel 7+). For any app on a current Laravel version, the product decision is effectively "the capability is already in the platform — no new vendor." That reframes the roadmap item from evaluate a package to delete custom HTTP plumbing.
• Testing and mocking strategy. A wrapper is also a seam. Decide early whether HTTP calls are mocked at the wrapper boundary or stubbed lower down; this shapes test-suite conventions and CI runtime more than the specific library does.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase is on legacy Laravel 5.x/6.x or plain PHP on Guzzle 6, where the framework's built-in HTTP client does not exist.
• You need a small, fixed surface — headers, bearer/basic auth, JSON and form bodies, timeouts, retries, plus request-URI introspection for logging and debugging (added in v0.6.0) — and nothing exotic.
• You accept no upstream maintenance guarantee: the project was dormant from 2019-06-10 until a single small additive release, v0.6.0, which adds one request-URI accessor. One commit after a multi-year gap is a signal of residual life, not of a maintenance commitment. Treat it as vendored code you now own, with a named maintainer and a documented exit path.
• You have confirmed dependency compatibility (PHP version, Guzzle constraint) in a spike, not on paper — re-verified against v0.6.0 rather than assumed from the prior release.

Look elsewhere when:

• Laravel 7+ — use the framework's HTTP client; it is the successor design and is maintained alongside the framework.
• You need concurrency/pooling, streaming, async, or PSR-18 interchangeability — go to Guzzle directly.
• Security or compliance expectations require actively patched dependencies. An unmaintained package that transitively pins an old Guzzle is a supply-chain and CVE-exposure conversation you will have to have at review time; v0.6.0 does not change that.
• The requirement is one or two calls total. The wrapper overhead exceeds the boilerplate it removes; a plain Guzzle call is fine.
• The team is already fluent in Guzzle and has an existing client abstraction. Adding a second idiom costs more in consistency than it saves in keystrokes.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small, free, MIT-licensed helper that makes outbound API calls shorter and more consistent. It is not a strategic dependency — it is a convenience layer that saves us boilerplate on integration work. Importantly, the same design now ships inside modern Laravel, so on a current upgrade path our recommendation is to use the framework's built-in version and carry no extra vendor at all. Net position: no new spend, no lock-in, and a one-page exit plan if we ever do adopt it.

To engineering (the real message): Zttp is a readable façade over Guzzle, nothing more — it does not replace Guzzle concepts, so it does not hide failure modes. Adopt it only for legacy stacks (Laravel ≤6 / Guzzle 6) where the built-in client is unavailable. The v0.6.0 release adds request-URI introspection — useful for logging and debugging the actual endpoint hit after redirects — but it is a single accessor and does not change the maintenance verdict: upstream is still superseded, and we should explicitly fork-or-vendor rather than depend on the repo's cadence. For anything on Laravel 7+, we use the HTTP client the framework already gives us and retire any bespoke wrapper. Either way the win is the same: every integration reads the same way, and we stop paying the boilerplate tax per vendor.

Decision requested: approve standardizing on the pattern (fluent, expressive HTTP calls, consistent response object); approve the package itself only as a stopgap for legacy services, with a scheduled migration. The pattern approval is unchanged by v0.6.0; the package approval remains a stopgap, and the added URI accessor is a nice-to-have, not a reason to expand its scope.