I am implementing an API generator for Drupal that supports JSON API. One of the things that I am missing is the ability to provide different sparse fieldsets for items included via different relationships.
I am solving that by using dot notation in the fields parameter. Imagine that you have a record label that can manage bands and individual artists. In turn each band can have artists as members of the band. My goal would be to be able to include the individual artists with 3 fields and band member artists with 1 field. I achieve that by doing fields=individualArtist.field1,individualArtist.field2,individualArtist.field3,band.members.field4, instead of doing fields[artists]=field1,field2,field3,field4.
I believe that this adds an extra pinch of flexibility.
I agree that this is something that should be supported and it may be added to the spec in the future. I’ve bookmarked this issue as a reminder to myself.
Until then, consider using a custom query parameter to support this in your particular API. API-specific query parameter names must contain at least one non a–z character, so I’d recommend something like fields-by-path. Then, I guess, just omit fields[TYPE].
Each individual resource in a compound document may be included via its membership in multiple relationships. For example, a single person might be included as both an author and an editor. This is why fields are specified per-type and not per-relationship.
I suppose that a custom solution might return a union of fields based upon the different relationships each individual resource is referenced by. However, this kind of flexibility would definitely add complexity to implementations.
I suppose that a custom solution might return a union of fields
I agree with the union of fields, after all that is what clients are doing as of now.
However, this kind of flexibility would definitely add complexity to implementations.
Right now I’m going to use this as an extension. If you think that it’s worth having a collaborative effort on this maybe we can put the extension definition in the extensions page. That way this behavior stays optional.
If you want to do that, I’ll draft an initial spec for the extension in a github gist for you to review.
I think this could definitely be a candidate for an extension, although we’re still finalizing our extension mechanism. It’s TBD how many “official” extensions we’ll support vs. providing a discovery service for extensions.
For now, a link here to your gist could be useful for others.