Json Request Bundle Laravel Package

Getting Started

Framework mismatch first: sunmediatv/json-request-bundle is a Symfony bundle, not a Laravel package. It targets Symfony's HttpKernel (argument resolvers / param converters) and Validator. You cannot composer require it into a Laravel app and have it "just work" — there is no ServiceProvider, no facade, no config/*.php.

In a Symfony app:

1. composer require sunmediatv/json-request-bundle
2. Register SunMediaTv\JsonRequestBundle\JsonRequestBundle in config/bundles.php
3. Read the bundle's DependencyInjection/*Extension.php and its argument resolver / param converter first — the README on a 0-star repo is often stale.
4. First use case: a POST /api/widgets endpoint where the controller typehints a DTO. The bundle deserializes php://input and hands you a validated object.

If you're on Symfony ≥ 6.3, use native #[MapRequestPayload] instead — same outcome, maintained.

In Laravel, the honest path is to vendor the DTOs + constraints and deserialize yourself (see Implementation Patterns).

Implementation Patterns

• DTOs + symfony/validator constraints. Annotate properties with #[NotBlank], #[Length], #[Type], etc. The bundle's job is to serialize the JSON into the DTO and then run the validator — if you skip constraints you just get a hydrated object with no safety.
• One DTO per endpoint. Sharing request DTOs across actions causes validation-group drift. Keep them flat and purpose-built.
• Nested / collection payloads. Define child DTOs and let Symfony's serializer hydrate arrays of objects; verify the bundle doesn't flatten them.
• Laravel integration pattern. Drop the bundle integration, keep the DTO classes, and hydrate/validate manually:
  • Deserialize with symfony/serializer (or spatie/data-transfer-object) in a FormRequest::prepareForValidation().
  • Validate with Laravel's Validator or symfony/validator — pick one and stay consistent.
  • Return 422 for validation failures, 400 for malformed JSON.
• Error contract. Decide before writing code whether malformed JSON → 400, validation → 422, wrong Content-Type → 415. Lock it down in controller tests.
• Testing. Cover (a) malformed JSON, (b) missing Content-Type, (c) empty body, (d) each validation rule violation.

Gotchas and Tips

• Maintenance risk is the headline gotcha. 0 stars, 0 dependents, unknown publisher activity. Treat it as reference code, not a dependency. Vendor or fork it if you must use it.
• Content-Type gate. The resolver typically requires application/json. A missing header yields a silent 415/400 — the most common "it just doesn't fire" bug.
• Empty vs malformed vs invalid. Three distinct failure modes and three distinct status codes. Verify the bundle's default behavior before shipping.
• Validation groups. Reused DTOs silently validate under the Default group only; scoped rules may not be exposed by the bundle's config.
• Extension point. If the argument resolver doesn't cover your case, override the service in config/services.yaml with decorates:. Inspect Resources/config/services.yaml inside the bundle to see what's decoratable.
• Debugging order. dump($request->getContent()) → confirm Content-Type → confirm the controller typehint matches a registered resolver. That resolves ~90% of issues.
• Recommendation for production Laravel. Skip this package. FormRequest + symfony/serializer or a maintained DTO package gets you the same ergonomics without the unmaintained-Symfony-bundle baggage. For Symfony apps, use native #[MapRequestPayload].