Comment 1 for bug 1751040

Agreed that we may want to filter out extensions that won't participate in returned payload formation. One thing worth noticing is that I don't think we actually send all the data to the client that then filters out unneeded fields, as you seem to imply. Instead, we call db_utils.resource_fields(res, fields) before passing the payload dict to the root api layer, the function that filters out fields not explicitly requested. If that's the case, I am not sure which new API tests you suggest to implement. (The current API behaviour is already as expected; of course additional coverage for the 'fields' feature is welcome if it's not good enough, but this matter is independent of the proposal).

My understanding is that in case of what you propose, we would need to know which fields are generated by each registered extension, to know which extension to call to. Then extensions could also do additional filtering by themselves in case when they serve multiple fields. This probably requires a new extension registration API that would support both of these features. Is it what you envision?