A municipal hospital campus must inventory thousands of devices from a controller API without client timeouts. Which retrieval pattern best scales?
Select an answer to reveal the explanation.
Short Explanation
Huge inventories are like patient charts—you do not dump the whole medical records room into one elevator. Page through the controller API until you have everyone. One giant GET times out; stopping after page one leaves wards uncounted.
Full Explanation
Large municipal campuses querying controller inventory APIs commonly receive paginated results. Automation must fetch inventories in bounded pages until complete so the job builds a full device list without unbounded responses or silent truncation. Pagination is an EI programmability competency whenever controllers protect themselves with page sizes.
Requesting the entire inventory in one unbounded GET and raising the client timeout to hours stresses controllers and still often fails. Hard-coding a single page of fifty devices ignores the rest of the campus and produces incomplete compliance or automation inputs. Exporting only syslog and reconstructing inventory by parsing hostnames cannot replace authoritative inventory objects.
Exam caveat: implement next-cursor/offset handling exactly per OpenAPI and stop only when the API signals completion. Operational check: page through a lab controller until exhausted, assert totals match the GUI, and fail loudly on mid-walk errors. Cache immutable fields where allowed to reduce repeated full walks for civic nightly jobs. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.