Currently when querying for Collections, we can only return 20 elements, requiring that we have multiple features with pagination or content sources with multiple calls the collections API when we populate more than 20 items in a collection.
Michael Newman
We use pagination right now; we do paginate anytime we use collections in our content sources. We make additional requests because the collection content source doesn't provide all the fields we need, so we pepper these into the content from the Collection API already.
We frequently have 25-30 stories on a PageBuilder page, and we are then required to make three calls to the API.
I understand the tradeoffs of size, but the Collection API makes the content sources larger and slower than they need to be and is different from other content source calls. Responsible developers use Arc's APIs, but I think this 20 story limitation is not built this way. If a content source could reasonably have this much content without slowing the page (and I would argue that 25 stories are way lighter than an entire Pagination logic being built into the page), I think the source API should support this.
Hi! Sorry that my previous comment wasn't clear. The /collections endpoint in Content API does support pagination up to 500 total elements. The pagination specs can be seen in the API docs in ALC, and a comparison of the different Content API endpoints is presented in this document . The 20 element limit is for a single page.
Could it be possible to allow for 20-40, 40-80 and so forth?
Hi Michael -- The limit of 20 what put in place in order to ensure no responses from Content API were too large. We'll continue to look at the size of responses coming back from Content API and see if it makes sense to up to the limit. Thanks!