Every team that builds a JSON API eventually has the same argument. Should relationships be nested or side-loaded? Is the ID a string or an integer? How does the client ask for fewer fields? You can settle it in a wiki page, or you can adopt JSON:API , a spec that already answered all of those questions. The catch in Laravel has always been that adopting the spec meant adopting a package, plus that package's opinions about routing, schemas, and controllers.

Laravel 13 removes that catch. It ships JsonApiResource , a first-party resource class that extends the JsonResource you already know and produces spec-compliant output. It handles resource objects, relationships, include , sparse fieldsets, links, meta, and the application/vnd.api+json header.…