Domain 6.5 | Automation and Programmability — 10% of exam
Learning Objectives
By the end of this lesson, you will be able to:
- Describe REST’s core characteristics: stateless, HTTP-based, and broadly language-agnostic.
- Correctly map each CRUD operation to its corresponding HTTP verb.
- Explain the difference between PUT and PATCH as two distinct forms of “update.”
- Explain which HTTP methods are idempotent and connect this to the idempotency concept from objective 6.1.
- Recognize common HTTP status code categories and what each range generally indicates.
Key Terms Glossary
| Term | Definition |
|---|---|
| REST (Representational State Transfer) | An architectural style for APIs, characterized by statelessness, use of standard HTTP methods, and resource-based URIs. |
| Stateless | A property where each API request contains all information needed to process it, with no reliance on stored session state from previous requests. |
| CRUD | The four fundamental data operations: Create, Read, Update, Delete. |
| Endpoint | A specific URI representing a resource that an API request can be directed at. |
| PUT | An HTTP method that replaces a resource’s entire representation. |
| PATCH | An HTTP method that applies a partial update to a resource. |
| HTTP status code | A three-digit code returned in an API response indicating the outcome of a request. |
REST’s Core Characteristics
REST (Representational State Transfer) is the dominant architectural style for modern network device and controller APIs, and three characteristics explain why it became so widely adopted specifically for this purpose.
REST is stateless — each individual request contains all the information the server needs to process it, without relying on the server having remembered anything from a previous request. This might sound like a minor technical detail, but it has real practical consequences: a stateless API can be called from any client, at any time, without needing to first establish or maintain a persistent session, and any request can be handled by any available server instance in a load-balanced environment without needing that specific instance to have “remembered” an earlier interaction with that same client.
REST operates over standard HTTP, the same protocol underlying ordinary web browsing. This means a REST API can be interacted with using tools and libraries that already exist virtually everywhere — a web browser, a command-line tool like curl, or an HTTP library available in essentially every modern programming language — rather than requiring specialized, protocol-specific client software the way some older API styles did.
REST is human-readable and straightforward to work with from virtually any programming language or automation tool, largely because of its typical data encoding (JSON, covered in more depth below and in objective 6.7) and its reliance on familiar, well-understood HTTP concepts rather than an unfamiliar, bespoke protocol.
Resource-Based Endpoints
REST APIs organize functionality around resources, each identified by its own endpoint — a specific URI representing that resource. A typical network API might expose an endpoint like /api/v1/interfaces/GigabitEthernet0-1, representing one specific interface as a distinct, addressable resource. This resource-based structure is what makes REST’s HTTP-verb mapping work cleanly.
The same endpoint can respond differently depending on which HTTP method is used against it — a GET request to that endpoint retrieves the interface’s current data, while a DELETE request to the exact same endpoint removes it (or, more realistically for something like a physical interface, might return an error indicating that particular resource type doesn’t support deletion). The endpoint identifies what you’re interacting with; the HTTP method identifies what you’re doing to it — two independent pieces of information combining to fully specify a single API request.
CRUD Operations Map Directly to HTTP Verbs
This is a critical mapping to memorize, since it appears directly and via inference throughout scenario-based questions on this objective:
| CRUD Operation | HTTP Verb |
|---|---|
| Create | POST |
| Read | GET |
| Update | PUT or PATCH |
| Delete | DELETE |
Create operations — adding a new resource that didn’t exist before — use POST. Read operations — retrieving existing data without changing anything — use GET. Update operations — modifying an existing resource — use either PUT or PATCH, depending on the specific nature of the update (covered in detail immediately below). Delete operations — removing an existing resource — use DELETE.
PUT vs. PATCH: Two Distinct Forms of “Update”
Both PUT and PATCH modify an existing resource, but they do so in genuinely different ways, and this distinction is worth holding precisely rather than treating the two as interchangeable synonyms.
PUT replaces a resource’s entire representation. If you PUT an updated version of an interface’s configuration object, you’re expected to send the complete object — every field, including fields you don’t actually want to change — because PUT’s semantics assume the request body represents the resource’s full, new state. Omitting a field in a PUT request can result in that field being reset to a default value or removed entirely, since the server treats the PUT body as the complete replacement, not a partial instruction.
PATCH applies a partial update — you send only the specific fields you actually want to change, and everything else on the resource remains untouched. If you only need to update an interface’s description without touching any of its other settings, PATCH is the semantically correct choice, since it doesn’t require you to resend the entire object just to change one field.
This distinction matters practically: using PUT when you only intended a partial change risks accidentally clearing fields you never meant to touch, simply because they weren’t included in the request body you sent.
A Concrete Illustration
Consider an interface resource with three configured fields: description, VLAN assignment, and administrative status. If an engineer wants to change only the description and sends a PUT request containing just the new description field, a strict implementation of PUT semantics could interpret the missing VLAN and administrative status fields as an instruction to reset them to their defaults — silently changing settings the engineer never intended to touch at all.
Sending the same change as a PATCH request containing only the description field avoids this risk entirely, since PATCH’s semantics explicitly mean “apply only what’s included here, leave everything else exactly as it is.” This is precisely why choosing correctly between the two isn’t a stylistic preference — it’s a decision with genuine, sometimes destructive consequences if gotten wrong in a production environment.
Idempotency and HTTP Methods: A Direct Connection to Objective 6.1
Recall objective 6.1’s definition of idempotency: applying the same operation repeatedly produces the same end result, without accumulating unintended side effects from repetition. This concept applies directly and concretely to HTTP methods, and recognizing which methods are idempotent and which aren’t is a genuinely practical skill, not just a theoretical classification exercise.
GET, PUT, and DELETE are idempotent. Calling GET on the same endpoint multiple times simply retrieves the same data repeatedly, with no side effects at all. Calling PUT with the same complete resource representation multiple times produces the same end state each time — the resource ends up looking identical regardless of how many times that exact PUT request is sent. Calling DELETE on the same resource multiple times results in that resource being absent either way — the first call removes it, and subsequent identical calls simply confirm it’s already gone (typically returning an appropriate “not found” response rather than an error indicating something went catastrophically wrong).
POST is generally not idempotent. Since POST’s semantics are “create a new resource,” calling the same POST request multiple times typically creates multiple new resources, one per call — exactly the kind of accumulating side effect objective 6.1 identified as the defining characteristic of non-idempotent behavior. Sending the same “create a new VLAN” POST request three times could result in three separate VLAN resources being created, unless the API specifically implements additional safeguards to prevent this.
This connection matters practically for automation reliability: a script that retries a failed request automatically (a common and reasonable pattern when a network request might have failed due to a transient issue rather than a genuine error) behaves safely if it’s retrying an idempotent GET, PUT, or DELETE — worst case, it repeats a harmless operation. That same automatic retry pattern applied to a POST request risks creating duplicate resources if the original request actually succeeded but the confirmation response was lost, which is exactly the scenario objective 6.1’s idempotency discussion warned against in the abstract, now made concrete through actual HTTP method behavior.
HTTP Status Codes: Reading the Outcome of a Request
Every REST API response includes an HTTP status code — a three-digit number indicating what happened. Recognizing the general category a status code falls into, without needing to memorize every specific code, is a practical, testable skill:
| Range | General Meaning | Example |
|---|---|---|
| 2xx | Success | 200 OK, 201 Created |
| 4xx | Client error — something wrong with the request itself | 400 Bad Request, 401 Unauthorized, 404 Not Found |
| 5xx | Server error — something wrong on the server’s end | 500 Internal Server Error |
A 2xx response confirms the request succeeded — 200 OK for a general success, 201 Created specifically confirming a new resource (from a POST request) was successfully created. A 4xx response indicates a problem with the request itself — 400 Bad Request for malformed request data, 401 Unauthorized for missing or invalid authentication credentials, 404 Not Found for a request targeting a resource or endpoint that doesn’t exist. A 5xx response indicates the problem lies on the server’s side rather than with anything the client did wrong — 500 Internal Server Error being the most general example, indicating something failed on the server while processing an otherwise valid request.
This categorization is genuinely useful for troubleshooting: a 4xx response tells you to look at what you sent (the request), while a 5xx response tells you the problem is likely outside your immediate control, on the receiving system itself.
A Few Specific Codes Worth Recognizing by Name
Beyond the general category, a handful of specific codes come up often enough to be worth recognizing directly rather than only their broader range. 200 OK is the generic success response for most GET, PUT, or PATCH requests. 201 Created specifically confirms a POST request successfully created a new resource, distinct from a generic 200 precisely because it communicates that something new now exists as a result of the request. 400 Bad Request indicates the request itself was malformed in some way the server couldn’t even parse or understand.
401 Unauthorized indicates missing or invalid authentication credentials — the request needs to prove who’s making it before the server will consider it further. 403 Forbidden is a related but distinct code worth distinguishing from 401: it means the credentials were understood and accepted, but the authenticated identity simply isn’t permitted to perform this specific action — an authorization failure rather than an authentication one, echoing the exact same distinction between these two concepts covered back in objective 5.8’s AAA discussion. 404 Not Found indicates the requested endpoint or resource simply doesn’t exist at the given URI.
REST APIs as Northbound APIs
This connects directly to objective 6.3’s northbound/southbound API discussion: REST is very commonly the specific technology used to implement a northbound API, since its characteristics — stateless, HTTP-based, broadly accessible from any programming language — fit naturally with how business applications, orchestration systems, and automation scripts need to interact with a controller from above. When an application requests “provision a new VLAN for this department” through a controller’s northbound API, that request is very often, in practice, an HTTP POST sent to a specific REST endpoint, carrying a JSON body describing the desired VLAN configuration.
Recognizing These Concepts in a Described Scenario
A meaningful part of this objective’s practical skill is correctly identifying which HTTP method or status code category a described scenario calls for, rather than only reciting the mapping table in isolation. A scenario describing “adding a brand new VLAN that didn’t exist before” calls for POST. A scenario describing “checking an interface’s current status without changing anything” calls for GET. A scenario describing “changing only one field on an existing object, leaving everything else untouched” calls for PATCH specifically, not PUT.
A scenario describing “replacing an object’s entire configuration with a completely new version” calls for PUT. A scenario describing “removing a resource that no longer exists” calls for DELETE. And a scenario describing a script safely re-running the same request without unwanted side effects is implicitly describing one of the idempotent methods — GET, PUT, or DELETE — while a scenario describing unexpected duplicate resources appearing after a retry is implicitly describing a problem with a non-idempotent POST request instead.
Common Misconceptions
- “REST APIs require a persistent, ongoing connection between client and server.” REST is explicitly stateless — each request is self-contained, with no requirement for a maintained session or persistent connection between individual requests.
- “PUT and PATCH are interchangeable ways of saying ‘update.'” PUT replaces the entire resource representation; PATCH applies only a partial update — using the wrong one can unintentionally clear fields you didn’t mean to touch.
- “All HTTP methods are idempotent, since they’re all just ‘requests.'” GET, PUT, and DELETE are idempotent; POST generally is not, since repeated POST requests typically create multiple new resources rather than converging on the same end state.
- “A 4xx status code always means the server is broken.” 4xx codes indicate a problem with the request itself (something the client sent), while 5xx codes indicate a problem on the server’s side — this distinction meaningfully changes where to look first when troubleshooting.
- “REST is the only architectural style ever used for network APIs.” REST is the dominant style specifically referenced at the CCNA level, but other API styles and protocols exist (including NETCONF, covered in objective 6.3, which uses a different underlying approach entirely) — REST’s dominance doesn’t mean universal exclusivity.
Frequently Asked Questions
Does a REST API always use JSON specifically? JSON is the dominant format in modern network APIs and the primary focus of objective 6.7, but REST APIs can technically use other formats, including XML, less commonly today — REST as an architectural style doesn’t strictly mandate one specific data format, even though JSON has become the practical default in most modern implementations.
Why does statelessness matter for automation and scalability specifically? A stateless API can be called by any automation script at any time without first needing to establish and maintain a session, and requests can be distributed across multiple server instances in a load-balanced deployment without needing any single instance to have “remembered” a specific client’s prior interactions — both properties that matter considerably at the scale automation is typically deployed to address.
Can a single API endpoint support multiple HTTP methods? Yes, commonly — the same endpoint URI (say, /api/v1/interfaces/{id}) might support GET (retrieve that specific interface’s data), PUT or PATCH (update it), and DELETE (remove it), with the specific HTTP method used determining which CRUD operation is actually performed against that same resource.
What authentication methods do REST APIs typically use? Common approaches include API keys (a unique credential included with each request), token-based authentication (often obtained through an initial login exchange and then included in subsequent requests), and basic authentication (a username and password, though less commonly used alone in security-conscious modern deployments) — the specific mechanism varies by platform, but some form of credential is nearly always required for anything beyond trivial, genuinely public endpoints.
Is memorizing every specific HTTP status code necessary for this objective? No — recognizing the general category (2xx success, 4xx client error, 5xx server error) and a small handful of especially common specific codes (200, 201, 400, 401, 404, 500) covers the practical, testable skill this objective actually requires, rather than needing comprehensive memorization of the full official status code registry.
REST APIs, HTTP Methods & Status Codes Quiz
REST, CRUD, PUT vs PATCH, Idempotency, HTTP Status Codes & Northbound APIs
Summary
REST is stateless, operates over standard HTTP, and is broadly accessible from virtually any programming language or automation tool — characteristics that explain its dominance for modern network device and controller APIs.
CRUD operations map directly to HTTP verbs: Create=POST, Read=GET, Update=PUT or PATCH, Delete=DELETE — a mapping worth memorizing cold, since it appears directly and via inference throughout scenario-based questions and real API design.
PUT replaces a resource's entire representation; PATCH applies only a partial update — using the wrong one for a partial change risks unintentionally clearing fields that weren't included in the request, sometimes with genuinely destructive consequences.
GET, PUT, and DELETE are idempotent, directly connecting to objective 6.1's idempotency concept; POST generally is not, since repeated identical POST requests typically create multiple new resources rather than converging on the same end state, which matters directly for the reliability of automated retry logic.
HTTP status codes fall into recognizable categories — 2xx success, 4xx client error, 5xx server error — and REST is commonly the specific technology implementing the northbound APIs discussed in objective 6.3.
The 401 vs. 403 distinction mirrors the authentication-versus-authorization distinction from objective 5.8's AAA discussion — one means "we don't know who you are," the other means "we know who you are, but you can't do that."
