Http Accept Laravel Package

Product Decisions This Supports

• API content negotiation and versioning: HTTP Accept header parsing underpins decisions like "serve JSON vs. XML," "route to /api/v2," or "return 406 Not Acceptable" — capability that directly shapes public API contracts and client onboarding.
• Build vs. buy: This is a narrow, well-bounded utility (parse Accept, Accept-Language, Accept-Encoding, quality values). Buying is cheap; building is a distraction from core roadmap work. The v1.0.0 stable tag lowers the "will this break under us" objection that typically blocks adoption of 0.x dependencies.
• Multi-format and multi-locale product bets: If the roadmap includes downloadable exports, report formats, or per-request locale selection driven by Accept-Language, this package is a supporting enabler rather than a feature in itself — worth slotting in as a foundation item, not a roadmap line item.
• Platform standardization: A single, documented negotiation layer reduces bespoke str_contains($request->header('Accept'), ...) checks scattered across controllers — a maintainability and correctness decision more than a feature decision.
• Migration decision (new in v1.0.0): The composer package name changed. Any existing prototype pinned to the old name requires a dependency swap; this is a decision point for teams that trialed the 0.x line.

When to Consider This Package

Adopt when:

• You need correct handling of quality values (q=0.8), wildcards (*/*, application/*), and multi-token headers — cases where naive string matching produces wrong results.
• You are building or extending a public/partner API with more than one response representation or more than one API version resolved from headers.
• You want locale or encoding negotiation handled by a focused, testable component instead of ad-hoc code in middleware.
• You accept the trade-off of a small, single-maintainer package for a low-surface-area utility.

Look elsewhere when:

• Laravel's built-ins already cover you. Request::accepts(), Request::prefers(), and Symfony's AcceptHeader handle the common cases. If you only need "does the client accept JSON," do not add a dependency.
• You need full RFC 7231/9110 compliance with an audited test suite, or enterprise support. Prefer a widely adopted alternative (e.g., willdurand/negotiation) or your framework's HTTP layer.
• Supply-chain policy requires vendor-backed or high-adoption packages. A brand-new 1.0.0 from a single author will likely fail internal dependency review regardless of code quality.
• You were on the 0.x line and cannot absorb a package rename. Stay pinned until a planned migration window; do not upgrade mid-sprint.

v1.0.0-specific gating: The parser refactor plus the composer rename means this is a breaking release. Treat it as a fresh dependency evaluation, not a patch. Require the team to re-run negotiation edge-case tests against your actual client traffic before rollout.

How to Pitch It (Stakeholders)

To executives (30 seconds): We are evaluating a small open-source PHP component that lets our API correctly read what clients ask for — format, language, version — instead of guessing. It reached a stable 1.0 release this week. Cost is effectively zero, it removes a class of bug from our API surface, and it is easy to replace. The risk is that it is maintained by one person and just renamed its install package, so I recommend adoption only behind a thin internal wrapper so we can swap it out without touching product code.

To engineering leads: v1.0.0 is a stability signal but also a breaking change — the composer package name is now asispts/http-accept, and the parser was refactored in the same release. Before adopting, confirm whether Laravel's existing accepts()/prefers() already satisfy the requirement; if it does, we should not add the dependency. If we do adopt, wrap it in a single ContentNegotiation service, pin the exact version, and add tests for q-values, wildcards, and multi-token headers. Do not use it as a substitute for proper API versioning strategy.

Recommendation: Conditional adopt. Worth a timeboxed spike (~half a day) only if we have a concrete negotiation requirement that framework primitives cannot meet. Otherwise defer and revisit if the package gains adoption and a second maintainer.