RESTCONF: the router's datastore, over HTTP
Every mechanism has a step-by-step animation, the configuration explained line by line and the exam notes. Where a parameter changes the outcome, you get a simulator in which you change it yourself.
TL;DR
RESTCONF (RFC 8040) exposes a device's datastore as HTTP resources: the URL is the path in the YANG tree (module:node/list=key), the body is JSON or XML (application/yang-data+json), and the methods say what you do — GET reads, POST creates a child, PUT replaces, PATCH merges, DELETE deletes. Each request is applied directly to running, with no candidate, lock or commit; the response is an HTTP code plus, on an error, an ietf-restconf:errors body with an error-tag. On IOS-XE you start it with restconf, ip http secure-server and ip http authentication; you discover the root from host-meta and the modules from yang-library; the RPCs live under /restconf/operations; YANG Patch adds atomic edits, NMDA separates running from operational, and NSO offers the same API with transactions across the whole fleet. Most incidents come from a missing module prefix on augmented nodes, a PUT with a partial body, a POST on an existing resource and configuration not saved to startup.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between platforms and between the RFC and its implementations. In the animations, the configuration lines used in the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of a large warehouse with numbered shelves and standard request slips: you write on the slip the action (let me look, add a box, replace the box, fill in the box, take the box out), the shelf's address exactly as in the catalog and the language you want the answer in, and the clerk hands the slip back stamped with a number. The shelves change on the spot; the vault (startup) doesn't, unless you explicitly ask for a copy.
The model holds up to §11. From §12 on (security in detail, tools, layer-by-layer troubleshooting), it breaks; see the full analogy and its limits in §16.