Rest Bundle Laravel Package

Getting Started

Read this first: it is not a Laravel package. symfony-bundles/rest-bundle is a Symfony bundle. It ships a Bundle subclass, a DependencyInjection/*Extension, and YAML/XML service wiring — none of which Laravel's PackageManifest will ever autoload. There is no ServiceProvider, no config/*.php, no facade. composer require-ing it into a Laravel app gets you classes on the autoloader and nothing else; the container never boots them.

So "getting started" for a Laravel developer means triaging what this thing actually is before you invest time:

1. Open composer.json first. Check the require block for symfony/http-kernel, symfony/framework-bundle, and the PHP constraint. If it pins Symfony 2.x/3.x, the code predates PHP 7.4 typed properties and you are reading archaeology, not a dependency.
2. Look at the repo name vs. package name. The package is symfony-bundles/rest-bundle but the repository is mgid/rest-bundle. That mismatch, combined with zero stars and zero dependents, strongly suggests an internal extraction or an abandoned fork. Treat it as a reference implementation, not a library.
3. Find the bundle class and the DI extension. That tells you what services exist. Then look for a base controller or a response/formatter service — that is where the actual opinionated REST behaviour lives.
4. Check for a Resources/config/ directory and any routing.yml. Those define the public surface.

First realistic use case: you are building a JSON API in Laravel and want a sane response envelope, status-code mapping, and pagination contract. Read this bundle's controller base class and response factory, then reimplement the ~200 lines of ideas in Laravel using JsonResource, ResponseFactory, and Handler. That is the honest day-one workflow. Do not attempt to mount a Symfony HttpKernel inside a Laravel app to "reuse" it — the container, event dispatcher, and request/response classes are structurally incompatible and you will burn a week on a bridge for code you could rewrite in an afternoon.

Implementation Patterns

Since direct integration is off the table, the leverage is in pattern porting. Map what the bundle does onto Laravel primitives:

Response envelope → API Resources. If the bundle defines a standard payload shape (typically { data, meta, errors }), do not hand-roll it in every controller. Create an abstract ApiController with respond() / respondError() helpers, or better, lean on JsonResource plus a small ApiResponse value object. Keep the envelope in one place so a future breaking change is a one-file edit.

Error mapping → Exception Handler. Symfony bundles of this vintage usually register an exception listener that converts domain exceptions into HTTP status codes. In Laravel this is App\Exceptions\Handler and render(). Port the mapping table, not the listener: ValidationException → 422, ModelNotFoundException → 404, a custom DomainException → 409. Centralising this is the single highest-value thing you can lift from the package.

Pagination contract → LengthAwarePaginator. Check whether the bundle normalises pagination metadata (page, per_page, total, last_page). If its shape differs from Laravel's default, decide once which shape your API promises and wrap the paginator in a resource so the wire format is stable regardless of what the ORM returns.

Content negotiation → middleware. If it inspects Accept headers, that is a middleware in Laravel, not a controller concern. A small ForceJsonResponse middleware is usually all you need.

Workflow for evaluating each class:

1. Read the class, note its single responsibility in one sentence.
2. Ask "which Laravel primitive replaces this?" (ResponseFactory, FormRequest, Resource, Middleware, Handler, Policy).
3. Port only if the Laravel primitive is missing or genuinely worse. Most of the time it isn't.

Integration tip if you are truly running a hybrid: the only survivable path is process-level separation — a Symfony service exposing HTTP, called by Laravel via Http:: — never shared process, never shared container. If that sounds like overkill, it is, and it confirms the reimplement-in-Laravel conclusion.

Gotchas and Tips

• Autoload collisions are real. A Symfony bundle's composer.json frequently requires symfony/* packages at versions that conflict with what's already resolved in a modern Laravel app. composer require can silently downgrade a dozen transitive packages before it fails. Run composer require --dry-run first, always.
• The zero-dependents signal is the biggest gotcha. No dependents means no one has hit the edge cases for you and no one will fix them. There is no security advisory pipeline watching it. Pin nothing to it in production.
• Configuration is Symfony-style. You will not find config/rest.php with env() calls. Config lives in DependencyInjection/Configuration.php (the TreeBuilder) and is injected as service arguments. Read that file to understand defaults — it is the most information-dense file in the repo.
• Debugging a bundle without a running app is hard. There is no php artisan tinker path. If you genuinely need to see it execute, spin a throwaway Symfony skeleton in a separate directory, wire the bundle per its README, and observe behaviour there. Keep it isolated.
• Watch for annotations. Older REST bundles lean on @Route / @Method docblock annotations and SensioFrameworkExtraBundle. Those are removed in Symfony 6+ and have no Laravel analogue. Do not port annotation-driven routing; Laravel's route files are strictly better here.
• Extension points are container tags and compiler passes. If you were hoping to "hook in" the way you would with a Laravel package event, you cannot from outside Symfony. This is another reason the code is read-only for you.
• Licence and provenance. Check LICENSE and the last commit date before copy-pasting code into a commercial Laravel codebase. "Zero stars, no dependents" often correlates with an unclear licence or a fork whose upstream terms were never carried over. Reimplementing the idea is always safe; copying the file may not be.
• The genuinely reusable bits are small and worth extracting deliberately: the status-code mapping table, the error envelope shape, and any pagination-link generation logic. Everything else is Symfony plumbing that has no meaning in Laravel.

Verdict for a Laravel developer: treat this repository as a design document, not a dependency. Budget an hour to skim the controller base and exception handling, then close the tab and implement the same conventions with JsonResource, Handler, and a thin ApiController. That gets you the package's opinions with none of its framework baggage.