Support 'fields' for PageModelAPI to control which parts should be included in the response

Email thread copy:

> Hi Ard,
> Regarding the flexibility of the PMA (or CMA), I would also suggest to consider the introduction of a "fields" parameter as part of that API. Not sure if the "fields" option belongs to the REST standards, but lately I've been noticing - especially in headless commerce API - the usage of such parameters (e.g. fields) more and more often. Probably you are already familiar with it, but it basically enables client applications to fetch only what they desire.
> In my opinion an option like this would enable:
> - A more flexible (sometimes easier and maybe cleaner) API interaction
> - Performance improvements, potentially..
>
> This option could be achieved without introducing any GraphQL support, that probably would require more work. And the benefits listed above are somehow relevant in SaaS.
>
> Moreover, I've also observed that commerce vendors provide a set of predefined values for the "fields" parameter. As example, SAP Hybris provides 3 predefined fields - BASIC, DEFAULT, FULL - where the API response changes accordingly.

Yes, supporting 'fields' parameters is a simple approach to have a bit
more control by rest api users what to return. It is simpler (but less
powerful) than graphQL and trivial to implement for the PMA. Our
fields for example could be 'page' (or some other term) and 'content'
to start with, and for content we could perhaps also enhance it to
something like 'content.title, content.links' to only include the
title and links of content section.

IIRC there is already support for a query parameter how deep the
linked content should be included.

I do think for performance reasons we will need this sooner or later
(or support graphQL which is a much bigger thing)