I85PREP
⌘ K
CWIIP study materials
CWIIP study resources

CWIIP: Systems Development Using APIs, Programming and Libraries

CWIIP · Work through your exam, one topic at a time.

All guide sections

Systems Development Using APIs, Programming and Libraries

What this domain tests

CWIIP expects working knowledge of how integration code talks to platforms: REST semantics, contract handling, credential flows, resilience patterns and dependency hygiene. Questions are scenario-based - pick the correct status code, retry policy or versioning approach.

REST fundamentals

  • Stateless request/response over HTTP; resources identified by URIs; verbs GET, POST, PUT, PATCH, DELETE.
  • Idempotency: GET, PUT and DELETE are idempotent; POST is not. That distinction decides whether an automatic retry is safe.
  • Status codes: 200 OK, 201 Created, 202 Accepted, 204 No Content, 400 client error, 401 unauthenticated, 403 unauthorized, 404 not found, 409 conflict, 429 rate limited, 500 server failure, 503 temporarily unavailable.
  • Define the contract with OpenAPI 3 so client SDKs and mocks can be generated; version in the path (/v1/...) and treat it as a compatibility promise.
  • Paginate (limit/offset or cursor) and filter server-side; never assume the first page is the whole dataset.

Credentials and resilience

  • OAuth 2.0 client credentials for machine-to-machine; short-lived bearer tokens refreshed before expiry. API keys are simpler but coarser and harder to rotate.
  • Timeouts on every call; retries with exponential backoff plus jitter, bounded in attempts, and only for idempotent operations or when an idempotency key is supported. Honour Retry-After on 429/503.
  • Circuit-breaker and queue-and-forward patterns protect a gateway from broker or API outages.

Libraries and dependencies

  • Isolate per project with a virtual environment; pin versions in requirements.txt or a lockfile; understand semantic versioning and read changelogs for breaking changes.
  • Wrap third-party SDKs behind a thin adapter so an upgrade touches one module.
  • Unit-test with mocked HTTP (responses/respx) and test the error paths, not just the happy path.

Worked example

A gateway POSTs a provisioning record and receives 503. Blindly retrying the POST risks duplicate records, because POST is not idempotent. Correct handling: retry only if the API accepts an Idempotency-Key header (send the same key, server deduplicates), otherwise query the resource to check whether the record was created, then proceed. Add exponential backoff with jitter and a cap of five attempts, log each attempt with a correlation ID, and alert after the cap.

Traps

  • Returning 403 when the real problem is a missing or expired token (401).
  • Retrying non-idempotent POSTs into duplicate records.
  • Ignoring pagination and silently truncating data.
  • Unbounded retries without jitter, causing a thundering herd.
  • Unpinned library versions breaking a production deployment; secrets committed in source.