Dedicated support for Laravel 13's first-party JsonApiResource

[WendellAdriel]

Scribe version

5.9

Your question

Context

Laravel 13 shipped first-party JSON:API support through Illuminate\Http\Resources\JsonApi\JsonApiResource. It extends the regular JsonResource, so Scribe doesn't crash on it, but the generated response isn't quite right, and I think we can close that gap with a small, focused change.

Two possible approaches

Minimal fix (correct response rendering)

Detect when the resource extends JsonApiResource, build the synthetic request with ?include= populated from the resource's declared relationships (and optionally ?fields[type]= for full coverage), and switch the Accept header to application/vnd.api+json. The existing pipeline handles the rest. Small, self-contained, lives inside ApiResourceResponseTools.

Broader fix (above + query parameter documentation)

Same response fix, plus a strategy that auto-documents the JSON:API query params for each endpoint: include as an enum of available relationships, fields[type] per resource type. This requires reflection on toRelationships() and handling nested includes, so it's more code and more design decisions, but it gives users a spec that matches how JSON:API consumers actually call the API.

Questions

Before I start working on a PR, I'd rather hear which direction (if any) feels right to you:

• Is approach 1 welcome on its own?
• Would you prefer approach 2, or would you rather land 1 first and treat the query-param piece as a separate follow-up?
• Anything about the architecture or extension surface I should know about before diving in?

I'd be happy to work on a PR for either approach, just let me know which one fits best with where you want Scribe to go.

Docs

• I've checked the docs, the troubleshooting guide, and existing issues, but I didn't find a solution