Rest Server Laravel Package

Product Decisions This Supports

• API architecture spike, not a dependency decision. innmind/rest-server is best treated as a reference implementation for hypermedia-style REST APIs (HATEOAS, content negotiation, typed resource representations), not as a library you ship. It supports the decision "should our public API be resource-oriented with discoverable links?" by giving engineers a working, opinionated example to react to.
• Build vs. buy vs. borrow. The package lets the team compare a bespoke hypermedia layer against an off-the-shelf one. Given the adoption signals (2 stars, 0 dependents, archived), the realistic outcome is "borrow the patterns, build our own thin layer" — this package supplies the vocabulary and edge cases for that conversation.
• Standards and contract decisions. It informs decisions around media types, link relations, and resource versioning — the things that are expensive to change after an API is public.
• Roadmap input for API discoverability. If the roadmap includes a public/partner API, evaluating hypermedia patterns early is cheaper than retrofitting linking and versioning later. This package is a low-cost way to pressure-test that bet.
• Not a feature-delivery decision. It should not appear on a roadmap as "adopt package X." It funds a spike, a design doc, or an architecture review — nothing more.

When to Consider This Package

Consider it when:

• You are running a time-boxed architecture spike (1–3 days) on hypermedia/HATEOAS API design and want a concrete PHP reference.
• Your team already works in the Innmind/functional-PHP ecosystem (immutable structures, Maybe/Either, explicit composition) and wants to see how a REST layer is expressed in that style.
• You need typed, self-describing resource representations and want prior art before designing your own.
• You are evaluating whether Laravel's conventional resource/controller model is sufficient, and want a deliberately different point of comparison.

Look elsewhere when:

• You need a production dependency. Archived status, 2 stars, and zero dependents mean no security patches, no PHP-version upkeep, and no community answers. Adopting this as a runtime dependency is a maintenance liability you would have to own outright.
• You need Laravel-native ergonomics — routing, middleware, Eloquent integration, auth scaffolding. This is not that; expect to write glue.
• You need OpenAPI generation, authn/authz, rate limiting, caching, or observability out of the box.
• Your team is not fluent in functional PHP. The cognitive overhead will dominate the value, and onboarding cost is real.
• You need hiring signal or vendor support. Neither exists here.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a free, MIT-licensed PHP package for building hypermedia REST APIs. It is archived and effectively unused — two stars, no downstream projects — so we are not proposing we build on it. We are proposing a short, low-cost engineering spike to study its design patterns before we commit to an API architecture. Cost: a few engineering days, zero license spend, zero vendor lock-in. Benefit: we avoid discovering API design mistakes after our API is public, which is where the real cost sits.

For engineering leadership: Treat innmind/rest-server as documentation with executable examples, not as a library. Its value is in showing a rigorous, typed approach to resource linking and content negotiation in PHP. The spike output is a design note and a recommendation — adopt the patterns, hand-roll a small internal layer we control, or conclude that Laravel's conventional REST model is good enough. Explicit non-goal: adding it to composer.json for anything customer-facing. The archived status means we would inherit 100% of the maintenance burden, and with zero dependents there is no ecosystem to lean on.

For the engineering team running the spike: Read the source and the tests; reproduce two or three representative endpoints in a throwaway branch. Document what it gets right (typed representations, explicit links, negotiation) and what it costs (functional-PHP fluency, no Laravel integration, no auth/OpenAPI/observability). Come back with a one-page recommendation and a rough effort estimate for the equivalent in our stack. Do not merge it into main.