This topic is not about response structure, please discuss that topic here: Discussion regarding the complex response structure for REST & GraphQL (Developer Experience)
As mentioned in a news post in our Discord last week we wanted to setup this discussion around how we are handling population of relations, media fields, dynamic zones, and components in Strapi v4.
If you haven’t already please read the following documents, pull requests, or issues before commenting:
- Current Documentation: REST API - Strapi Developer Docs
- WIP Documentation PR (more examples): Rewrite REST examples to use QS + Misc fixes by derrickmehaffy · Pull Request #541 · strapi/documentation · GitHub
- Original v4 RFC published in May 2021: rfcs/xxxx-v4-rest-api.md at v4/rest-api · strapi/rfcs · GitHub
- Feature request for DZ/Compo population: Auto-populate option for Components & Dynamic Zones · Issue #11852 · strapi/strapi · GitHub
Currently purposed features:
- Addition of more wildcard filter options (eg:
- Option to specify a default population via some file or other method per content-type (default without modification will be no population)
- Add a global config option to allow populating some number of levels
Current status on v4:
We will not auto populate any field by default within Strapi as the purpose for not doing so is largely performance but also security as within the v4 if a role doesn’t have access to the
find controller on a related content-type it is not possible to populate it.
Making this change on v4 is not possible as it would be considered breaking, but we are open to feature requests that extend past the default.
Future status on the future (v5, v6, v7+):
As we look to the future we want to hear from you on how you consume data, why you need deep population of data vs multiple requests. What would make things easier and why.
Likewise we want to start educating users on good practices and hopefully documenting best practices from us on usage of various parts of Strapi (not just population).