Weave Code
Symfony Json Request Laravel Package
gowork/symfony-json-request
A Symfony package for handling JSON HTTP requests more cleanly. It helps decode application/json request bodies and integrate them with Symfony's Request object and controllers, simplifying JSON API endpoints and request data access.
Symfony Json Request
Frequently asked questions about Symfony Json Request
- Does gowork/symfony-json-request work with Laravel?
- Not natively. It is a Symfony bundle whose value is delivered through a Symfony kernel.request event listener, and Laravel does not dispatch Symfony HttpKernel events. Composer may install it against the shared symfony/http-foundation 7.x dependency, but the package's listener will not fire in a Laravel request lifecycle. Making it work requires custom Laravel middleware that calls the decoder directly, which reduces the package to a thin wrapper around json_decode(file_get_contents('php://input')).
- How do I install gowork/symfony-json-request?
- Install it with Composer using composer require gowork/symfony-json-request. In a Symfony application you would then register the bundle in your bundle configuration so its kernel.request listener is active. In Laravel there is no Laravel package auto-discovery or service provider integration, so installation alone does not wire it into your HTTP pipeline.
- Which Laravel and Symfony versions does it support?
- Version 0.3.0 adds Symfony 7 support, and the package targets Symfony HttpFoundation request handling. Laravel 11 and later depend on symfony/http-foundation 7.x, so Composer resolution is more likely to succeed than before. However, there is no evidence of a tested compatibility matrix across Symfony 6.4 and 7.x or PHP 8.2, 8.3, and 8.4, so do not treat install success as Laravel support.
- What problem does this package solve that Laravel's Request::json() does not?
- It addresses a Symfony HttpFoundation gap: $request->request is populated from form-encoded bodies but not from application/json payloads. Laravel's Illuminate\Http\Request overrides all(), input(), and json() to read from the decoded JSON body, so that problem does not exist in a Laravel application. In Laravel the package has no behavioral gap to fill.
- Can I activate its Symfony kernel.request listener in Laravel?
- No, not without pulling in symfony/http-kernel and effectively running a second request pipeline alongside Laravel's own kernel and router. That conflicts with Laravel's bootstrapping and creates two sources of truth for the request body. The only defensible approach is to import the decoder class directly and call it from your own middleware.
- Is gowork/symfony-json-request safe for production in a Laravel API?
- It is not recommended for production in a Laravel codebase. Adoption is effectively zero, with roughly 2 stars and 0 dependents, so there is no downstream pressure to surface bugs or provide community regression testing. The technical risk is moderate to high, mainly supply-chain related, and the integration path is functionally pointless when Laravel already handles JSON natively. If you only need the decoding behavior, a short local helper is safer than adding a dependency.
- How do I handle JSON request bodies in Laravel without this package?
- Use Laravel's existing request API: $request->json('key'), $request->input('key'), or $request->all() for decoded JSON data, and FormRequest classes for validation. If you need the untouched payload, use $request->getContent() for the raw body. No extra Composer package is required for standard JSON API endpoints.
- Does it preserve the raw request body for webhook signature checks?
- You should not rely on the package's decoded request data for HMAC or webhook signature verification. Signature checks depend on the exact untouched input stream, so read it with $request->getContent() before any transformation. Any abstraction that encourages reading the body through a decoded bag invites re-serialization bugs and mismatched signatures.
- How does it handle malformed JSON or deeply nested payloads?
- The package documentation does not establish a tested edge-case matrix for malformed JSON, depth limits, or charset negotiation on Symfony 7. Symfony 7 support appears to come from a single community pull request rather than a documented CI matrix over problematic payloads. In a Laravel app, validate and catch JSON decoding errors yourself using Laravel's request handling and standard json_decode error checks.
- Is gowork/symfony-json-request actively maintained and tested?
- Maintenance evidence is weak: version 0.3.0 merged an external PR for Symfony 7 support, which is a weak positive signal that the maintainer accepts contributions. One merged PR is not a support commitment, and there is no clear tested version matrix, changelog policy, or security disclosure process described. With 2 stars and 0 dependents, ask the maintainer directly about CI coverage and support expectations.
Weaver
How can I help you explore Laravel packages today?