Domain 1 of 4 · Chapter 6 of 6

Consuming REST APIs at Scale

Unlock the complete study guide + 1,040 practice questions across 16 full exams.

Bundled into the existing Designing, Deploying and Managing Network Automation Systems premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

  • At scale, a REST client is a loop
  • Paginate until the stop signal
  • Stay under the rate ceiling, back off when pushed
  • Authenticate once, then carry the credential
  • Retry only what is transient and idempotent
  • What the exam stem looks like

Four concerns of consuming a REST API at scale

ConcernWhat breaks at scaleThe ruleCisco signal to watch
CompletenessOne response holds only the first pageLoop until the stop signalShort page (offset/limit) or no rel=next (cursor)
Rate ceilingToo many requests too fast are rejectedThrottle under the limit; honor Retry-After429 Too Many Requests with Retry-After
AuthenticationRe-login on every call is wastefulLog in once, cache and reuse; refresh on 401X-Auth-Token / JSESSIONID + X-XSRF-TOKEN
Error handlingSome failures a retry cures, some it cannotRetry only transient AND idempotent2xx / 3xx / 4xx / 5xx status class

Decision tree

Response arrived? No response: timeout / conn error 2xx or 3xx? Success: proceed / follow 3xx Retryable? 429 / 5xx Permanent 4xx: 401 refresh + retry once 403 / 404 fix, then stop Idempotent method? GET / PUT / DELETE Back off + retry urllib3 Retry adapter POST: idempotency key or check-first, then retry Yes No 2xx / 3xx 4xx / 5xx other 4xx Yes (429/5xx) transient Yes No (POST)
Cheat sheet

Cheat sheet

  • Offset/limit pagination iterates until a short page returns
  • Cursor pagination follows nextPage or Link rel=next
  • A single response rarely holds the full result set
  • The server caps page size regardless of the client request
  • 429 Too Many Requests must honor Retry-After
  • Exponential backoff with jitter spreads retries
  • Client-side throttling avoids hitting the limit at all
  • Distinguish retryable from non-retryable responses
  • OAuth2 client-credentials yields a Bearer access token
  • Persistent auth caches and refreshes tokens, not per-request
  • Catalyst Center issues an X-Auth-Token to reuse
  • vManage uses a session cookie plus a CSRF token
  • Handle responses by HTTP status class
  • 401, 403, and 404 demand different reactions
  • Only idempotent methods are safe to blindly retry
  • A requests Retry adapter automates backoff and retry

Unlock with Premium — includes all practice exams and the complete study guide.

References

  1. https://developer.cisco.com/docs/catalyst-center/
  2. https://developer.cisco.com/meraki/api-v1/pagination/
  3. https://developer.cisco.com/docs/sdwan/authentication/
  4. https://developer.cisco.com/docs/catalyst-center/get-device-list/
  5. https://www.rfc-editor.org/rfc/rfc8288
  6. https://requests.readthedocs.io/en/latest/api/
  7. https://www.rfc-editor.org/rfc/rfc6585
  8. https://developer.cisco.com/meraki/api-v1/rate-limit/
  9. https://www.rfc-editor.org/rfc/rfc9110
  10. https://docs.python.org/3/library/email.utils.html
  11. https://docs.python.org/3/library/random.html
  12. https://requests.readthedocs.io/en/latest/user/quickstart/
  13. https://docs.python.org/3/library/asyncio-sync.html
  14. https://datatracker.ietf.org/doc/html/rfc6749
  15. https://datatracker.ietf.org/doc/html/rfc6750
  16. https://developer.cisco.com/docs/catalyst-center/authentication/
  17. https://datatracker.ietf.org/doc/html/rfc9110
  18. https://datatracker.ietf.org/doc/html/rfc8040
  19. https://requests.readthedocs.io/en/latest/user/advanced/