I need to read more carefully. :winking_face: I now see what @Ruchika_Abbi meant.
Indeed, the API (like almost every API) returns all [populated] fields even when using a view ID despite the fact that the view itself may be designed to be more concise. As such, this is intentional, but one might ask - should it be intentional?
Perhaps any API queries based on a view should only return the fields marked visible to the view context.
It’s not obvious, but his would be bad; very bad.
Imagine an API process that was built when View (x) had five fields. Now it has 11 fields, and 2 of the first five have been hidden. Calamity ensues.
Imagine a certain view represents the most useful filtering of data for a given API process, but that API process must also use field values that were never intended for human consumption. API developers would find themselves in a cul-de-sac.
Conclusion: views, correctly expose all fields.
If you want to filter fields from result sets, you may do so with the “fields” parameter.
Correct. And, it is equally as brittle. An unsuspecting user with authority could change the filter, upsetting any API processes that depend on the view. As such, I encourage clients to name views in a manner that help to avoid API disruption.
This changes under the new proposed security features that Airtable should be releasing soon which I believe will make it easier to defend against arbitrary view tampering.