REST APIs: what you ask for, what you get and why
Every mechanism has a step-by-step animation, the configuration explained line by line and exam notes. Where a parameter changes the result, you get a simulator where you change it yourself.
TL;DR
A REST API is a contract over HTTP: the resource is a URI, the action is the method (POST creates, GET reads, PUT replaces, PATCH modifies, DELETE removes), the result is the status code (2xx worked, 4xx you got it wrong, 5xx the server did) and the data travels as JSON. Each request is complete (stateless): it carries the token, obtained once with the credentials and valid for a limited time (60 min on Catalyst Center). Large collections come paginated, requests that are too frequent get 429 with Retry-After, long operations answer 202 with a task to follow, and events arrive through webhooks. In a Cisco network, the controllers (Catalyst Center, Meraki, vManage) expose intent APIs, while IOS-XE exposes the YANG models directly through RESTCONF and NETCONF. Most incidents come from untested expired tokens, missing Content-Type, bursts over the rate limit and verify=False.
How to read the notes: red = critical for the exam, green = theory, blue = numbers, yellow = pitfalls, cyan = differences between platforms, protocols and standards. In the animations, the configuration lines used at the current step are highlighted automatically; the ← → arrows change the step when the animation is selected.
The analogy, in short
Think of a restaurant: you don't walk into the kitchen, you tell the waiter what you want, from the menu. The order goes on a slip with a fixed format (what you do, which dish, remarks), the answer comes back on a slip too, with a short code at the top ("right away", "we're out", "the kitchen is closed"). At the door you show your ID once and get a wristband valid for that evening; the waiters don't remember anyone, which is why you write the table on every slip and show the wristband.
The model holds up to §9. From §10 on (the security of tokens stolen remotely, controllers that turn one request into dozens of configurations, tools on top of the API), it breaks down; see the full analogy and its limits in §16.