200-901 Cisco Platforms and Development Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The API uses page-based pagination with page and perPage parameters.

  Why it's wrong here

  A rel="next" Link header signals cursor or token-based pagination, where the client follows the supplied URL rather than incrementing page numbers. It tempts because page and perPage parameters do appear in some Meraki endpoints, making page-based pagination correct when the response returns explicit page counts instead of link headers.

• ✗

  The API uses offset-based pagination and the next page can be retrieved by incrementing an offset parameter.

  Why it's wrong here

  Link headers with rel="next" signal cursor-based pagination, where the server supplies an opaque token or URL; there is no offset parameter to increment. Offset pagination returns page/per_page metadata instead. Cursor pagination is correct when datasets change frequently, avoiding skipped or duplicated records.

• ✓

  The API uses Link header pagination and the next page can be retrieved by following the URL in the Link header.

  Why this is correct

  The Link header with rel="next" signals cursor-based pagination: the API returns a partial result set plus a URL for the following page. Following that URL directly retrieves the next batch, so the developer iterates until no rel="next" link remains.

• ✗

  The API uses cursor-based pagination with startingAfter/endingBefore parameters.

  Why it's wrong here

  Cursor-based pagination via startingAfter/endingBefore is a Cisco Meraki convention, but the scenario's Link header with rel="next" signals RFC 5988 web linking instead. Cursor parameters would be tempting when the API documents them explicitly for sequential traversal, yet here the response itself supplies the next-page URL, so no cursor values are needed.

Go deeper

Related to this question