Symfony Json Request Laravel Package

Getting Started

1. Install the package (v0.3.0 adds Symfony 7 support, so ^0.3 is the floor for Symfony 7 apps; Symfony 6.4 is still served by the same release):

   composer require gowork/symfony-json-request
   

2. Register the bundle (Flex may do this automatically; otherwise add it to config/bundles.php):

   return [
       // ...
       Gowork\SymfonyJsonRequest\JsonRequestBundle::class => ['all' => true],
   ];
   

3. Confirm the request listener is active. The package works by intercepting the request (typically on kernel.request, when Content-Type is application/json) and decoding the raw body into the request ParameterBag, so $request->request->get(...) behaves like a normal form submission.
4. First use case — swap this:

   $data = json_decode($request->getContent(), true);
   $name = $data['name'] ?? null;
   

   for this:

   $name = $request->request->get('name');
   

Look first at the package's DependencyInjection/ and EventListener/ (or EventSubscriber/) directories to see the listener priority and the exact Content-Type matching logic — that determines how it composes with your other kernel.request listeners. Also check composer.json for the Symfony constraint range: 0.3.0 broadened it to include Symfony 7, and that range is what actually governs whether the bundle installs cleanly alongside your framework version.

Implementation Patterns

Plain controller consumption. Once the listener runs, treat JSON payloads exactly like form posts. $request->request->all() returns the decoded associative array, and $request->request->get('user') returns nested arrays as-is. This lets you delete scattered json_decode($request->getContent(), true) calls.

Form and validator integration. Because the data lands in the request bag, $form->handleRequest($request) and $form->submit($request->request->all()) work with JSON payloads without a custom FormRequestHandler. A common pattern is a thin base controller or a RequestPayloadTrait that normalizes both form and JSON requests before handing off to the form.

DTO mapping. Combine with the Serializer:

$dto = $this->serializer->denormalize(
    $request->request->all(),
    CreateUserInput::class
);

This keeps validation (#[Assert\...]) on the DTO rather than in the controller, and the listener gives you a consistent array regardless of content type.

Middleware ordering. If you have authentication, rate-limiting, or tenant-resolution listeners, verify their priority relative to this package's listener. Auth listeners that parse the body themselves (e.g. HMAC signature checks over raw content) should run before any transformation, or read $request->getContent() directly rather than the parameter bag.

Upgrading to Symfony 7 / this release. 0.3.0 is a compatibility release, not a behaviour change — no listener, matcher, or naming changes were announced. Bumping from 0.2.x on a Symfony 6.4 app should be a drop-in; the real work only appears if you are also moving the app to Symfony 7, in which case run your functional JSON tests (below) as the regression gate rather than eyeballing the diff.

Testing. Functional tests using KernelBrowser should send JSON explicitly:

$client->request('POST', '/api/users', [], [], [
    'CONTENT_TYPE' => 'application/json',
], json_encode(['name' => 'Ada']));

Assert on the response, not on the request bag, so the test remains valid if you later drop the package — and so the same suite doubles as your Symfony 6.4 → 7 upgrade check.

Gotchas and Tips

• Content-Type gate. The listener almost certainly only fires for application/json (possibly +json suffixes). Requests with a missing or vendor-specific type like application/vnd.api+json may be skipped — check the matcher and, if needed, set the header in clients/tests. This logic was untouched in 0.3.0, so any matcher workaround you wrote for 0.2.x still applies.
• Overwrites, not merges. Decoding the body into $request->request typically replaces or populates the bag. Don't rely on query-string params appearing in $request->request; keep using $request->query for GET data.
• Invalid or empty JSON. Malformed JSON usually results in an empty bag rather than an exception, which silently produces "missing field" validation errors. Log or assert on $request->getContent() in a test if you need a hard failure. Worth a dedicated test when you upgrade, since a silently-empty bag looks identical to a broken listener.
• File uploads are unaffected. Multipart stays multipart; this only helps JSON. Endpoints accepting both should branch on $request->getContentTypeFormat().
• Version constraints when bumping. The Symfony 7 support lives in the composer.json constraint range. If your root composer.json pins symfony/framework-bundle loosely but this package stays locked at 0.2.x, you'll get a confusing solver conflict — run composer why-not gowork/symfony-json-request 0.3.0 before digging into the bundle itself.
• Security. Decoded JSON is untrusted input like any other — validate with the Validator or DTO constraints; never pass the raw array into mass-assignment paths.
• Debugging. If $request->request is unexpectedly empty, dump $request->getContent(), $request->headers->get('Content-Type'), and check debug:event-dispatcher kernel.request to confirm the listener is registered and its priority. On Symfony 7 the command output/verbosity differs slightly, but the event and listener names are the same.
• Extension points. Most such packages expose the listener as a service — you can decorate it, adjust its priority in services.yaml, or subclass it to add +json matching. Note that your Symfony version already offers $request->getPayload() / $request->toArray() (6.3+, including all of 7.x), so on a modern app this package is a convenience, not a necessity. The 0.3.0 release does show the package is still maintained, but it remains a small project (2 stars, no dependents) — vendor risk is real, so wrapping usage behind your own helper (or a single base controller) keeps removal trivial if you later standardise on getPayload().