I have a resource which includes certain attributes. These attributes can all be included using the fields[TYPE] parameter, and they can all be filtered and sorted.
I have some other attributes pertaining to a resource that I would like to include, but due to the way they are stored in the database, it would be impossible for me to support such features on these fields using a query builder as I am currently.
So, I would like to know would it be “atypical” to only support sparse fieldsets, filtering and sorting on only some (not all) attributes returned with a resource? Basically, these attributes will always be returned with the resource no matter what.
Is it much of a “common practice” to implement something like this?
I had a similar use case where we could not support filtering/sorting for all fields. We have opted for answering requests with an error status code and an error object identifying the part of the request that could not be processed.
Our reasoning was that silent failures were unacceptable. Of course we also needed to provide a documentation detailing what fields were supported for each case.
If you desire to validate incoming requests, JSON Schema may be an interesting option for you. Still, it should be ease to implement sparse fieldsets by removing fields just before answering the request.
P.s.: I checked the standard and it states
If a client requests a restricted set of fields for a given resource type, an endpoint MUST NOT include additional fields in resource objects of that type in its response.
So if you want to comply to the standard you MUST NOT answer additional fields when sparse fieldsets is used.