Rest Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for an API layer. This bundle is best read as a build pattern, not a dependency: it auto-derives REST endpoints from existing view controllers so you can ship a JSON surface without rewriting the app. The decision it informs is “do we hand-write a thin API adapter, adopt a framework like API Platform, or generate from existing controllers?” — and the answer for most teams will be one of the first two.
• API-first roadmap sequencing. If “expose our app as an API” is on the roadmap, this is evidence that auto-generation from controllers exists as a shortcut, but it comes with tight coupling between presentation and contract. That argues for budgeting explicit API design (OpenAPI spec, versioning, auth) rather than treating generation as the end state.
• Legacy modernization triage. Useful framing for a legacy Symfony monolith where the cheapest first step is “publish read-only JSON for the top N screens” before committing to a service extraction. This bundle demonstrates the mechanics of that spike.
• Platform mismatch check (important). Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle. For a Laravel shop this is a non-option for production and only useful as a design reference — that alone should close the “adopt as dependency” question.
• Use cases where the pattern fits: internal admin tooling, short-lived partner integrations, demo/prototype APIs, and transitional endpoints during a rewrite.
• Use cases where it does not: anything customer-facing with SLAs, anything touching PII, anything needing pagination/filtering contracts, authn/authz, or rate limiting out of the box.

When to Consider This Package

Consider it (as reference or fork) when:

• The codebase is Symfony, with many existing controllers and a mandate to expose JSON quickly.
• The scope is a timeboxed spike or internal tool, where the cost of replacement later is acceptable.
• You have engineering capacity to fork and own it — MIT license permits this, and given the maintenance signals, forking is the realistic mode of use, not composer require.
• You want to study the controller-to-resource mapping approach before designing your own adapter.

Look elsewhere when:

• Maintenance risk is disqualifying. Last release 2020-12-29, 3 GitHub stars, 0 dependents. That is effectively unmaintained; assume no security patching and no compatibility guarantees against current Symfony/PHP versions. An opportunity score of ~26 reflects exactly this.
• You need production API concerns — schema contracts, OpenAPI generation, versioning, serialization groups, auth, throttling, pagination. Use API Platform (Symfony) or Laravel API Resources / Sanctum (Laravel) instead.
• You are a Laravel team. Wrong ecosystem; no reason to bridge.
• Auto-exposing controllers is a security concern. Deriving endpoints from view controllers risks over-exposure of data and accidental write paths. Any adoption needs an explicit allowlist and a review of what each generated route returns.
• You need a vendor relationship. Zero dependents means zero community support surface; escalation is “read the source.”

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed open-source component that generates REST endpoints from an application’s existing screens. The idea is attractive — faster time-to-API without a rewrite — but the artifact is not a safe dependency: last shipped in December 2020, three stars, no downstream users, and it targets Symfony rather than our Laravel stack. Recommendation: do not adopt; spend at most a one-day spike to validate whether the pattern is worth building in-house. Cost of evaluating is near zero; cost of depending on it is unbounded maintenance and security exposure.

For engineering: Treat it as a reference implementation for controller-to-resource mapping, not a library. If the pattern proves valuable, we own a small internal adapter with tests, an explicit route allowlist, and contract tests — roughly a few days of work — which is cheaper over a two-year horizon than resurrecting an abandoned bundle. If we want a supported off-the-shelf answer, API Platform is the comparison to make.

Bottom line for the roadmap: this does not earn a line item. It earns a footnote in the “expose the app as an API” decision record, with the recommendation to design the contract explicitly and keep presentation and API layers decoupled.