Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 6.5 — Describe REST API characteristics

A REST-style API presents resources through identifiers such as URIs and uses HTTP requests and responses to interact with them. To read an API exchange, identify the resource, authentication context, method, request body, response status, representation, and resulting state. A familiar HTTP verb suggests an operation, but the API's official contract defines exact behavior.

Map CRUD to HTTP carefully

Create, read, update, and delete are data-operation concepts. Common mappings are POST for create, GET for read, PUT or PATCH for update, and DELETE for removal. PUT commonly represents replacement of a resource and PATCH a partial change, but implementations vary. Never infer safety or idempotence from a verb without the documented API semantics.

Query parameters can filter or paginate a collection. Headers carry metadata such as accepted representation, content type, authorization, and conditional request information. A request body may contain JSON or another supported encoding. Encoding describes data representation; it is not encryption.

Treat status and body as evidence

A response includes a status code, headers, and often a body. Two-hundred-range codes generally indicate successful processing, four-hundred-range codes point to request, authentication, authorization, or resource problems, and five-hundred-range codes indicate server-side failure. Exact meaning still comes from the contract. An accepted asynchronous request may not mean the network change has finished.

Parse the response instead of searching raw text for one word. APIs may return structured error fields, task identifiers, pagination links, or operational state that must be polled and validated.

Secure authentication and authorization

APIs may use tokens, certificates, sessions, signed requests, or other methods. Use protected transport, least-privilege scopes, controlled secret storage, and expiration. Never embed live tokens in source code, lab resources, browser console examples, or logs. Authentication proves an accepted identity; authorization still determines allowed operations.

Worked scenario

A client sends PATCH /devices/edge-07 with JSON that changes a description. The server returns a task identifier and HTTP 202. The request was accepted for processing, not necessarily completed. The workflow follows the task resource, checks final success or failure, reads the device resource again, and compares the resulting state with intent.

Verification evidence

Record a redacted request method, resource, content type, nonsecret identity, response status, correlation or task identifier, parsed error or result, and post-change state. Handle timeouts, retries, and rate limits explicitly. Retrying a non-idempotent create without a request identifier can produce duplicates.

Common traps

• Saying JSON encoding encrypts data.
• Treating every 2xx response as completed network state.
• Assuming PUT and PATCH are interchangeable in every API.
• Logging tokens for troubleshooting.
• Ignoring pagination, asynchronous tasks, and retry effects.

Readiness checklist

• I can map CRUD concepts to common HTTP methods.
• I can read URI, headers, status, and body together.
• I distinguish authentication, authorization, and transport protection.
• I verify resulting state after an accepted request.