Api Response Laravel Package

Product Decisions This Supports

• API response contract standardization. Informs the decision to adopt a single response envelope (data / meta / errors, stable error codes, consistent HTTP status mapping) instead of ad-hoc controller returns. This is a cross-cutting contract decision that affects every consumer-facing endpoint and every SDK/client built on top.
• Build vs. buy, resolved toward "build thin." The package is MIT-licensed and small in scope (response factory + exception/formatting layer). v10.0.0 does not change this: its only substantive change is a major-version bump of its internal dragon-code/support dependency (6.0) plus a docs update — no new capabilities, no stated security fixes. The honest framing remains that this is a design reference, not a dependency. The build estimate for an equivalent internal formatter is small relative to the integration, upgrade, and fork-ownership risk of adopting an abandoned library.
• Roadmap sequencing for API versioning. The decision to lock a response shape now determines whether we can add fields (pagination meta, deprecation notices, request IDs) additively later. Getting this wrong is a breaking change for every client — this is a "decide early, decide once" item.
• Error-handling and observability strategy. A uniform error payload with machine-readable codes is a prerequisite for meaningful client-side error UX, support triage, and alerting on error-rate by code. This drives whether we need a global exception subscriber in the framework layer.
• Ecosystem and platform fit check. The package targets Symfony, not Laravel. For a Laravel codebase this is largely a non-decision: Laravel's API Resources, response()->json(), and exception handler already cover this ground with zero added dependency. This package is only relevant as prior art.
• Dependency-churn signal (new in v10.0.0). A major version bump that carries only an internal dependency-major bump and doc edits is itself a data point: the package's breaking-change cadence is decoupled from user-facing value. Adopting it means inheriting migrations like this one with no feature payoff — exactly the maintenance tax we would be signing up for.
• Use cases it genuinely serves as a reference: greenfield API surface design, an internal style guide for response envelopes, a migration spec when consolidating inconsistent legacy endpoints, and a checklist for what a response contract should include.

When to Consider This Package

Consider it (narrowly) only when all of the following hold:

• The codebase is Symfony (not Laravel) and already has a legacy dependency on this family of packages.
• The service is internal, low-traffic, or short-lived — an internal tool, a prototype, or a service scheduled for replacement — so an unpatched dependency is an accepted risk.
• You need a worked example of an envelope convention to copy into your own code, not a runtime dependency.
• Legal/licensing review is satisfied — MIT is permissive, so vendoring or reimplementing the pattern is clean.

Look elsewhere — or build in-house — when any of these apply:

• Long dormancy, not active maintenance. A multi-year gap followed by a v10.0.0 that contains only a dependency bump is not a revival of support; there is still no maintainer SLA, no security-patch commitment, and no evidence of a roadmap. Treat the major bump as a compatibility risk, not reassurance.
• Adoption signals are effectively zero (36 stars, 0 dependents, no release between 2022-04-20 and v10.0.0, low health score). No ecosystem validation, no Stack Overflow corpus, no third party who has hit your edge case.
• Laravel project. Use framework-native API Resources plus a small exception renderer. Adding a Symfony-oriented, effectively unmaintained dependency here is pure downside.
• Version currency matters. The v10.0.0 bump of dragon-code/support to 6.0 may carry its own PHP/Symfony floor changes; verify the transitive version matrix before anything else, and do not assume a 2026 release has been validated against the Symfony and PHP versions you run.
• You need pagination, HATEOAS, JSON:API, or OpenAPI-generated contracts. Reach for actively maintained options or generate the contract from the spec.
• You need SLAs, CVE response, or a vendor contact. Not available here.
• Total cost of ownership is a factor. Even at zero license cost, forking an abandoned package means your team becomes the maintainer — budget that explicitly, including future dependency-major migrations of the kind shipped in v10.0.0.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed library for standardizing API responses. A new major version (v10.0.0) has been published, but it contains only an internal dependency upgrade and documentation edits — no new features and no security fixes. We are still not recommending it as a dependency: it is effectively unmaintained, with negligible adoption, and the v10.0.0 release actually illustrates the problem — a breaking version number with no user-facing value. What we are taking from it is the pattern — a consistent response envelope with stable error codes — which we can implement internally at low cost and keep under our own maintenance. Net effect: we get the consistency benefit and avoid the supply-chain and ownership risk of an abandoned third-party package. No license spend; modest one-time engineering effort; no ongoing vendor exposure; recommendation unchanged by the new release.

For engineering: Treat dragon-code/api-response as a reference implementation, not a dependency. It is Symfony-targeted, has no dependents, and spent years dormant before shipping v10.0.0 — a major bump whose entire changelog is "bump dragon-code/support to 6.0" plus doc updates, meaning the breaking-change surface exists purely for a transitive dependency migration. If we are on Laravel, the framework already gives us the primitives; the work is a response formatter plus a global exception renderer, plus a written contract doc and tests. If we are on Symfony and want the shortcut, pin down the transitive PHP/Symfony compatibility matrix first and compare against a maintained alternative. Recommended decision: build the thin internal layer, cite this package as design prior art, and record the rejection rationale in the architecture decision log — including the v10.0.0 review — so it does not get re-litigated on the next release.