Collections API frequently requires a second query against Content API for fields that don't come from the Collections API.
For example we have a display where the copyright needs to be displayed with the story on a section page. To use the collection, we get the content for the display, then query the Content API with the ids of each story in the collection.
Another example is we have our app's homepage driven by a collection. We have all the information from that, except for all of the authors, so again we need to query the content API and pepper in the missing information on each call to the collections API.
Michael Newman
Hi Megan! Great news to read that the included_fields will be fixed so it works in Collection API requests; how will I know when it's done, so we can implement it? It would be great if you could tell my support team when its done, or me directly, I don't know what is best for you... thank you!
Hi Michael -- It looks like the Credits object for author information is already returned in the /content/v4/collections endpoint. If you continue to see it not appearing for some reason, please file an ACS ticket so we can look into why!
As for Copyright, we'll take a look at what other fields likely make sense to add to the Collections response and work to put adding it on the roadmap.
Hi Chjalmar -- Thank you for pointing this out! You are absolutely right that included_fields is supposed to work like the rest of the Content API. We've filed a bug ticket and will work to remedy this.
Agree absolutely. In our case, the need for filtering goes the other way: removing unused fields from the request's response payload for optimization.
Since before our release I have received many useful optimization requests and tips from our Support team. On of the most common ones is, one should filter the Content Source requests so one only asks for those ANS fields which are used for rendering.
This has been possible in the case of content api requests, and search api requests; but not so with collections api requests, and that situation is the expected behavior, as I can see in the API Docs:
https://....arcpublishing.com/alc/docs/swagger/?url=./arc-products/content-api.json#/Fetch/get_collections
Since our website administration strategy relies heavily on using collections to let content creators curate the homepage without actually having to use PageBuilder, in this way also avoiding filling StoryCards manually (which would multiply by many times both the number of api requests and the amount of work needed to curate the homepage); and since that strategy was previously shared with many people from our Arc support team, and was approved by all of them...
...we think that the collections API should allow the use of parameters like the ones used in search api (
_sourceIncludeand_sourceExclude) or content api (included_fieldsandexcluded_fields) to custom denormalize the api responses and reduce payload sizes when rendering content from collections. From our short experience and what we've seen when optimizing requests from other content sources, I am very confident that payloads would reduce at least half its size if we could remove some fields from the responses that we don't really need to render StoryCards, or anything for that matter, in Homepage and section covers...Hope this comes very soon! Thanks everyone!