- Does haddowg/json-api-symfony work with Laravel?
- No. It is a Symfony bundle built around Doctrine ORM, Symfony security expressions, and the Symfony Validator, and it ships no Laravel service provider, Eloquent data provider, or Laravel validation bridge. Treat Laravel support as an integration project your team owns rather than a configuration flag. If your application is Laravel-first, a native Laravel JSON:API package will cost far less.
- How do I install haddowg/json-api-symfony?
- Install it with Composer and register it as a Symfony bundle, then enable the extensions and per-type capabilities you need. It targets PHP 8 with Symfony and Doctrine ORM, so an existing Symfony application with Doctrine entities is the expected starting point. There is no Artisan installer, publishable config stub, or Laravel package auto-discovery support.
- Is there an Eloquent data provider for this package?
- No, only Doctrine. The real integration contract is DataProviderInterface, which in 1.0.0 also mandates relatedToOneMatches() and relatedToOneMatchesBatch(), plus DoctrineExtensionInterface::apply(), which now takes an ExtensionContext instead of loose arguments. An Eloquent adapter must be written against that typed contract, and because the typed constraint-translator extension replaced the Custom bridge, an Eloquent filter bridge has to target the typed API rather than the old one.
- Can I use Laravel's validator instead of Symfony's Validator?
- Not out of the box. The package integrates with the Symfony Validator bridge, so request validation and error mapping assume Symfony constraints. On Laravel you would need to translate validation failures into JSON:API error documents and wire them into the package's exception-to-error mapping seam yourself.
- How does authorization work, and can I use Laravel gates and policies?
- Authorization uses Symfony security expressions, so Laravel gates and policies are not supported directly. A resource's read-security expression now also gates GET /{type}/{id}/{rel} and /relationships/{rel}, relationships can be authorized independently of their parent, and collection reads require a securityList key. Porting that model to Laravel means writing an authorization bridge rather than changing a setting.
- What changed in version 1.0.0?
- Roughly 25 breaking changes landed in a single release: attributes are flattened, linkage methods were renamed to data, linkage is lazy by default, counting is opt-in, pagination is the single source of truth, the zero-config pivot filter (filter[position]) was removed, and the Custom constraint bridge was dropped. Security semantics also changed, so read expressions gate relationship endpoints and collection reads need a securityList key, which will surface as new 403s in code written against pre-1.0 behaviour.
- Which JSON:API features does this bundle actually cover?
- It is a spec-faithful implementation rather than a thin serializer. It covers resource objects, relationships and linkage endpoints, error documents, a consolidated query engine, cursor and keyset pagination, related collections, pivot filter operators, constrained existence, custom non-CRUD actions, the Atomic Operations extension, an async write seam with 202 and 303 responses, cache and deprecation headers, strict query parameters, write-only attributes, composite attributes, and an OpenAPI metadata layer. That breadth is why the Doctrine-shaped seams are the main integration cost.
- How are resource ids generated in this package?
- A 1.0.0 capability lets ids be custom-encoded or sourced from a policy, making id generation a policy decision instead of a fixed column read. The advertised id pattern is also bridged into the OpenAPI metadata. For an Eloquent adapter this helps, because you can map ids without forcing a particular database column shape.
- Is haddowg/json-api-symfony production ready and actively maintained?
- It is a real 1.0.0 with substantial functionality, but maintenance is concentrated in a single GitHub account with no foundation, corporate sponsor, or LTS policy. No release evidence shows a Laravel test matrix, so you would be adopting a package whose maintainers do not test your stack. Its build-time failure gating for polymorphic, Doctrine-column, pivot, and routed-but-unservable types is a genuine quality signal, but that gating is Doctrine-shaped and an Eloquent adapter inherits none of it for free.
- What are the alternatives for building a JSON:API in Laravel?
- For a Laravel application, a native Laravel JSON:API package or a transformer and serializer layer avoids writing providers, authorization, and validation bridges yourself. Consider haddowg/json-api-symfony only if you already run Symfony services alongside Laravel, or if strict spec fidelity, Atomic Operations, and the OpenAPI metadata layer justify the adapter work. Otherwise the integration cost outweighs the benefit.