Although, in our case, the filtering doesn't work fine with nested properties for post based resources, which would ve very handy for filtering meta fields, which are sub-properties of the meta property.
Of course the main problem here is my rough filtering, although checking every time whether a property is to be included in the response prior to process it might be a performance improvement.
eri-trabiccolo
commented
1 year ago
By default WordPress's REST API allow for filtering the response fields trough the
_fieldsglobal parameter: https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/#_fieldsThis already works because any response is filtered and the fields not included in
_fields(when supplied), will be automatically excluded.Although, in our case, the filtering doesn't work fine with nested properties for post based resources, which would ve very handy for filtering meta fields, which are sub-properties of the
metaproperty.That's because back in the days when I started implementing the first resources I decided, mainly out of laziness, to avoid checking every time whether a property was to be included in the response prior to compute it (e.g. https://github.com/WordPress/wordpress-develop/blob/6.0/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L1710) and instead process them all, and roughly filter them at end: https://github.com/gocodebox/lifterlms-rest/blob/1.0.0-beta-24/includes/abstracts/class-llms-rest-posts-controller.php#L903
Of course the main problem here is my rough filtering, although checking every time whether a property is to be included in the response prior to process it might be a performance improvement.