An offset/limit Cisco API does not return Link relations or page tokens. The latest response contains fewer items than the requested limit. What should the consumer conclude?
Select an answer to reveal the explanation.
Short Explanation
When the last elevator load has empty space, there is nobody left in the lobby. A page shorter than limit—or empty—means stop; asking for yet another full window wastes quota, and stopping after only full pages can drop the tail.
Full Explanation
Without Link relations or page tokens, short pages are the usual end-of-collection signal for offset/limit APIs. When the latest response contains fewer items than the requested limit (including zero), the consumer should treat that short or empty page as termination and stop requesting further windows. Continuing would either re-fetch empties or walk off the end of the municipal collection with no benefit.
Immediately requesting another full-size page because short pages always mean more data is hidden fails the common convention and can loop on empty tails. Stopping only after a full-size page, even if that drops the remaining tail, fails by discarding the last partial window’s items or never fetching them. Switching permanently to rel=next parsing even though the API never sent a Link header fails because there is no relation URL to follow.
Exam caveat: a short page caused by a transient filter quirk is rare—if docs define a different end signal, follow docs; otherwise short-or-empty is the DEVCOR-relevant default. Combine with a maximum page cap to bound runaway clients.
Operational check: set limit=50 against a 120-item fixture and confirm requests at offsets 0, 50, and 100, stopping after the 20-item final page with all 120 items aggregated.