Rest Bundle Laravel Package

Getting Started

Read this first: it is a Symfony bundle, not a Laravel package. There is no service provider, facade, publishable config, or config/rest.php. Laravel's HTTP kernel, router, and container are not the Symfony bundle system, so you cannot composer require this into a Laravel app and get behavior. "Day-to-day leverage" here means one of two things: you actually maintain a Symfony codebase, or you are mining the package for its pattern (auto-exposing existing view controllers as JSON/XML endpoints) and reimplementing it in Laravel.

Where to look, in order:

1. composer.json — Symfony version constraints. Last release Dec 2020 means Symfony 3/4/5 era; expect friction on Symfony 6/7.
2. The bundle class and DependencyInjection/Configuration.php — what is configurable and what services get registered.
3. Resources/config/ — service definitions and any routing file you must import.
4. The controller base class / trait and the event listener or kernel event subscriber — this is where the "view controller becomes a REST API" magic actually lives.

Minimal steps in a Symfony app:

1. composer require wobblecode/rest-bundle (check constraints first; you may need a fork or --ignore-platform-reqs).
2. Register WobbleCodeRestBundle in config/bundles.php (or AppKernel on Symfony 3).
3. Import the bundle's routing file in config/routes.yaml or routing.yml.
4. Retrofit an existing action: take a controller that currently returns a rendered view, opt it into the bundle's mechanism (base class, trait, or annotation), and hit it with Accept: application/json.

First use case: one controller action that serves HTML to browsers and JSON to API clients, driven by content negotiation, without writing a parallel API controller. That is the entire pitch — evaluate it against that single scenario before anything else.

If your actual target is Laravel: skip the package and copy the idea. A content-negotiation middleware plus JsonResource plus a respond() helper on a base controller gets you 90% of it in well under 100 lines.

Implementation Patterns

The pattern being sold: your existing controllers already build a view model; the bundle serializes that same model for API consumers and negotiates the format. Integration points to expect are a base controller or trait, a response/format listener, serializer configuration, and routing conventions.

• Retrofit, don't rewrite. Add the bundle's opt-in (base class/trait/annotation) to existing controllers and let Accept / _format decide HTML vs JSON. This is the lowest-risk adoption path and the one the package is designed for.
• Mount under /api. Import the bundle routes with a prefix so browser traffic keeps hitting HTML and API clients hit JSON. Avoids the classic "browser suddenly downloads a JSON file" failure.
• Explicit view models only. "Based on your view controllers" means whatever you hand the view becomes your API payload. Pass arrays or dedicated DTOs to the template, never live entities — otherwise lazy-loaded relations, password fields, and internal flags leak into responses.
• Test both formats. One functional test per action asserting text/html and application/json for the same route. Format negotiation bugs are invisible in manual browser testing.
• Separate serializer groups. If the bundle wires the Symfony Serializer, define groups per context (web view vs API) so the two consumers can diverge without forking controllers.
• Laravel equivalent. Content-negotiation middleware ($request->prefers(['html', 'json'])), JsonResource for shaping, App::abort(406) for unsupported formats, and a respond() helper on a base controller. Symfony equivalent without the bundle: FOSRestBundle + Symfony Serializer, or #[Route(defaults: ['_format' => 'json'])] with $request->getPreferredFormat().

Gotchas and Tips

• Abandonment is the headline risk. 3 stars, 0 dependents, last release 2020, effectively a single maintainer. No security patches, no Symfony 6/7 support, no community to answer questions. Treat the repo as reference code, not a dependency you put in production.
• Framework mismatch. The brief frames this for a Laravel developer, but the package is Symfony-only. Any guide telling you to install it in Laravel is wrong; there is no bundle registration path there.
• Constraint wall. Inspect composer.json before requiring. Expect symfony/*: ^3|^4|^5 pins that hard-fail on 6/7 — and forking to bump them is your own maintenance burden from day one.
• Format negotiation surprises. If the bundle keys off Accept, curl sends */* and browsers send text/html,...; you will get HTML where you expected JSON and assume the bundle is broken. Always test with an explicit Accept: application/json.
• Serialization leakage. Auto-exposing controller data is the fastest route to shipping internal fields. Audit every response shape; assume nothing is hidden by default.
• Route collisions. Imported bundle routes can shadow or be shadowed by your app routes. Run bin/console debug:router immediately after import and diff against the previous output.
• Debugging. debug:router, debug:container --tag=..., and reading the listener's getSubscribedEvents tell you when the bundle fires — kernel request vs response vs view. Most "it does nothing" reports are a priority or event-timing issue.
• Extension points to fork first. The base controller/trait, the serializer service alias, the format listener, and the configuration tree. Those four are where any real customization happens; if you must keep the package, vendor-fork it and pin the fork.
• Safer migrations. If you like the pattern, friendsofsymfony/rest-bundle is the maintained Symfony equivalent. In Laravel, the idiomatic move is middleware + API Resources, which you control entirely.