Restgeneratorbundle Laravel Package

Getting Started

What you're adopting. VoryxRestGeneratorBundle is a Symfony 2 code generator, not a runtime REST framework. It scaffolds a Doctrine-entity CRUD controller in the style of SensioGeneratorBundle, producing the five standard REST actions (list, show, create, update, delete) plus route/annotation boilerplate. The day-to-day value is skipping repetitive controller wiring — not getting serialization, pagination, auth, or API semantics for free.

Prerequisites.

• Symfony 2.x Standard Edition layout (app/console, app/AppKernel.php).
• A mapped Doctrine ORM entity.
• Composer.
• In practice, generated controllers tend to assume FOSRestBundle (for @View/format handling) and JMS Serializer. Check the generated code and add them if those annotations appear.
• PHP 5.x-era constraints; expect friction on PHP 7.2+ or Symfony 3+.

Install and register.

composer require voryx/restgeneratorbundle

// app/AppKernel.php
new Voryx\RESTGeneratorBundle\VoryxRestGeneratorBundle(),

Make sure annotation routing is enabled for your controller directory (routing.yml with type: annotation), or register the generated route resource explicitly.

Where to look first.

1. The README's usage section for the exact generator command and arguments.
2. app/console list to confirm the command name and options (it will be under the bundle's namespace).
3. The generated controller itself — for this package it is the real documentation.
4. The bundle's Controller/ directory for any base REST controller worth extending.

First use case. Pick one small entity (e.g. Post), run the generator, commit the output on a branch, and hit /posts.json (or the prefix you chose). Diff the generated code before customizing so you know exactly what the bundle contributed.

Implementation Patterns

• Treat generated output as scaffolding you now own. Commit it, then customize. Avoid regenerating over a modified controller; move reusable behavior into a project base controller or trait instead.
• Extract a BaseRestController. Centralize pagination, error envelopes, 404 handling, and entity lookup. Keep generated controllers thin so regeneration or copy-paste stays cheap.
• Never return raw entities. Use JMS serialization groups (@Groups, @Exclude) or FOSRest view annotations. Direct entity serialization is the fastest route to circular-reference recursion, N+1 queries, and leaked internal fields.
• Write actions need real input handling. Bind POST/PUT data through a Symfony Form with validation, or a dedicated DTO. Map validation failures to a consistent 400 body. Don't trust json_decode output blindly.
• Keep the {_format} convention. Preserve defaults={"_format"="json"} from the generator and add a per-resource route prefix. If you convert to YAML routing, keep method names aligned with the generated controller.
• Add collection concerns yourself. The generator won't paginate or filter. Add ?page, ?limit, and simple filters in the collection action, backed by Doctrine's Paginator or a paginator bundle.
• Security is external. Generated actions have no auth. Use security.yml firewall/access rules per path and HTTP method, plus voters inside the controller for ownership checks.
• Custom actions belong in the same controller. Add subresources or state transitions as explicit methods with @Route/@Method, and return proper status codes: 201 + Location on create, 204 on delete.
• Test every generated endpoint. List, show, create, update, delete, 404, and validation failure. Since the controller is generated, functional tests are your regression net when customizing.
• Consolidate across entities. Once several controllers exist, pull duplicated logic into services (EntityUpdater, PaginatorFactory) rather than duplicating generated code.

Gotchas and Tips

• Effectively legacy. Last release 2016, Symfony 2 only, unmaintained. Use it for an existing Symfony 2 codebase or a quick prototype; for new APIs prefer API Platform or a maintained FOSRestBundle/Lexik setup. Check composer constraints before planning any PHP/Symfony upgrade — this package can block it.
• Generator, not runtime. Expect no pagination, filtering, auth, rate limiting, content-negotiation edge cases, or standardized error format. Those are your responsibility.
• Annotation coupling. Generated controllers often depend on FOSRestBundle annotations and JMS Serializer metadata. Without those installed and configured, endpoints return HTML errors or fail to serialize. Verify the fos_rest format listener and view configuration.
• Entity exposure. Direct serialization causes circular references and N+1 queries. Use serialization groups, @MaxDepth, and join/eager fetching on collection queries.
• Format handling. Test with explicit .json URLs and with Accept headers. A missing/incorrect _format or Content-Type often yields 406/415 or an empty body. Check whether generated write actions expect JSON bodies or form-encoded data — older generators vary.
• Route collisions and plurals. Paths and route names are derived from the entity name. Odd plurals and clashes with existing routes need manual fixes. Run app/console debug:router after generating.
• Overwrite prompts. The generator may ask before overwriting. Never run it blindly on a customized controller; keep generated code under version control and copy patterns for new controllers instead.
• Doctrine assumptions. Actions typically use the default entity manager and Bundle:Entity repository strings. Multi-EM setups, custom repositories, or non-Doctrine sources require manual edits.
• CSRF vs. stateless APIs. Symfony's CSRF protection doesn't fit token-authenticated APIs. Disable it on API firewalls and use proper auth over TLS instead.
• Debugging. Use debug:router, the profiler's request/response panel, and explicit curl -i calls. Serialization exceptions frequently surface as bare 500s with no body — log them.
• Extension points. Override the base controller, decorate services (serializer, view listener), or copy the generator's templates into your app (SensioGenerator-style template overriding) to change generated output. If the bundle becomes a blocker, vendor/fork it — it is small enough to maintain locally.