A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
Every HTTP interaction has the same shape. The request line includes method (POST), path, and HTTP version. Headers carry metadata (auth token, content type, content length). An optional body carries data (here, the JSON payload). The response has a status line, response headers, and a body.
| Method | CRUD | Purpose | Idempotent? |
|---|---|---|---|
| GET | Read | Retrieve a resource | Yes |
| POST | Create | Create a new resource | No |
| PUT | Update (full) | Replace the entire resource | Yes |
| PATCH | Update (partial) | Modify part of a resource | Usually |
| DELETE | Delete | Remove a resource | Yes |
Idempotency matters. An idempotent operation produces the same result whether you run it once or ten times. GET, PUT, and DELETE are idempotent. POST is not — running POST twice creates two resources. This matters for automation: if a script retries on failure, an idempotent method is safe; a non-idempotent method creates duplicates.
For network automation, PATCH is often better than PUT. A PATCH changes only the fields you specify; a PUT replaces the whole object, potentially wiping fields you didn't include. If you PUT a device config with only the fields you wanted to change, the rest gets blanked. Always check whether your API supports PATCH and prefer it when it does.
HTTP methods follow CRUD semantics. Status codes communicate outcomes. PATCH for partial updates, POST for create, GET for read. Section 18 continues with DNA Center and hands-on automation.
Finish the lesson once you have worked through the material. This awards ★ 35 XP.