6.4 REST-Based APIs

What a REST API Is

REST (Representational State Transfer) is an architectural style for web APIs (Application Programming Interfaces). A RESTful API lets software talk to a controller or device over HTTP/HTTPS instead of a human typing CLI commands. You send an HTTP request to a URL endpoint and get back structured data — almost always JSON.

Example — list devices from Cisco Catalyst Center:

GET https://catalystcenter.example.com/dna/intent/api/v1/network-device
Authorization: Bearer <token>
Content-Type: application/json

Response (JSON):

{
  "response": [
    {
      "hostname": "SW-Floor1",
      "managementIpAddress": "10.0.0.10",
      "platformId": "C9300-48T",
      "softwareVersion": "17.9.1",
      "reachabilityStatus": "Reachable"
    }
  ]
}

The Six REST Constraints

The most-tested one is stateless: if a question describes "each request must include all information the server needs, such as the auth token," the answer is stateless.

HTTP Methods and CRUD

Every REST call uses an HTTP verb that maps to a CRUD operation (Create, Read, Update, Delete).

GET is safe (read-only) and idempotent; PUT and DELETE are idempotent (repeating them lands the same final state); POST is not idempotent (repeat it and you may create duplicates).

HTTP Status Codes

The first digit defines the class; memorize the class meanings and the common specific codes.

Trap: 401 vs 403 — 401 means you have not proven who you are; 403 means we know who you are, but you are not allowed.

Authentication

Cisco Catalyst Center, Meraki Dashboard, ACI, and SD-WAN (vManage) all expose REST APIs used exactly this way for automation.

On the Exam: Know the verb-to-CRUD mapping cold, recognize 200/201/401/403/404/500, and remember REST is stateless and returns JSON over HTTPS.

Anatomy of a REST Request and Response

It helps to see every moving part of a single transaction. A REST request has four pieces: the method (the verb such as GET or POST), the URI (the endpoint plus any resource identifiers and query parameters), the headers (metadata such as Authorization: Bearer <token>, Accept: application/json, and Content-Type: application/json), and an optional body (the JSON payload, used on POST, PUT, and PATCH but not on GET or DELETE). The server replies with a status code that tells you the outcome class, response headers, and a response body carrying the requested or created data.

Consider creating a VLAN on a controller. You send POST /api/v1/vlans with the header Authorization: Bearer eyJ... and a JSON body {"id": 10, "name": "SALES"}. If it works, the server returns 201 Created and a body echoing the new resource, often with the URI where it now lives. If your token expired, you get 401 Unauthorized. If the token is valid but your account cannot create VLANs, you get 403 Forbidden. If you posted to a misspelled endpoint, you get 404 Not Found. If your JSON was malformed, you get 400 Bad Request. And if the controller itself crashed mid-request, you get 500 Internal Server Error.

Walking that single example mentally lets you reconstruct most status-code questions on the exam from first principles rather than rote memory.

Why Statelessness Scales

Because REST is stateless, any server in a load-balanced pool can handle any request — there is no session pinned to one server that another would lack. That is why you must include the auth token on every call rather than logging in once and relying on the server to remember you. This property is what lets cloud platforms and SDN controllers serve thousands of automation clients simultaneously, and it is exactly the behavior the exam describes when it says "each request must contain all the information needed to process it."