According to the spec, sparse fieldsets are specified by whitelisting members, e.g. fields[article]=title,body will include the fields title and body and no others. The spec further says that member names can not start with e.g. - (hyphen/minus). Finally, the spec does not say what should happen for unrecognized or invalid names in the field name list, e.g. it does not specify what should happen if the client requests fields[article]=title,body,foobar when foobar doesn’t exist. I would assume it’s fine to just ignore foobar.
The way I see it, I can then say the following without breaking the spec in any way that seem to matter:
If you prefix ALL specified fields of a certain type with hyphen, those fields will be excluded, and all other fields will be included (and if at least one field does not start with a hyphen, all hyphen-prefixed fields will be ignored).
In other words, I could allow a request to specify fields[article]=-title,-body in order to to exclude title and body and include all other fields. This way I can allow both whitelist and blacklist approaches to sparse fieldsets. The only breakage I can see here is that if a fields parameter includes only unrecognized fields, that’s the same as no (recognized) fields, which would exclude all fields of that resource. But no-one who has read the spec would ever prefix all fields with a hyphen believing that they were now including the (illegally named) fields -title and -body, so this won’t be a problem in practice.
Am I correct in this? And are there any significant pitfalls I’ve overlooked?
The reason I have implemented this functionality in my API (still in development) is that during development/debugging, I find myself frequently wanting to exclude certain expensive/verbose fields and include all others, and for resources with 20-30 fields this quickly becomes very cumbersome if using a whitelist.