Open razvanMiu opened 1 year ago
My initial reaction is that I would rather avoid adding this complexity unless there is a good reason. Why is it not good enough to only use the data you need from the response?
One example of usage is that we have blocks that can embed content from other pages and we want to get only some specific metadata. If we get everything the response would be too big, especially if those pages have a lot of blocks. In my case I can avoid getting all the metadata field by making specific endpoints but I thought that making this generic would be useful.
Okay, that helps me understand the use case. I'll try to take a look at the PR soon and think about what would be the best way to do it. In terms of performance it would be best to use the summary serializer from catalog metadata so that it isn't necessary to load the full content object from the ZODB. I'm not sure if that belongs in the content GET service, or a new service. (It might be possible to get from the @querystring-search service already, using a path criterion with depth: 1 ... though, that would not handle well when content is moved to a new path... so, a UID criterion then)
My 0.02€...
There is no way to get only the desired metadatas in GET content