3.4Building code to meet a requirement

So far we have pinned down each platform's scope and the model-driven methods. This section, as a synthesis, addresses the judgment of turning a concrete requirement into a single piece of code. "I want a device list," "I want to notify a chat," "I need a list of wireless clients"—the goal is to be able to assemble which platform's endpoint, with which HTTP method, and what auth. In practice you are also tested on spotting what is wrong in a script someone else (or an AI) wrote.

3.4.1Typical tasks and their endpoints

• Fetching a device list—for an enterprise access network use Catalyst Center's Intent API (GET /dna/intent/api/v1/network-device, needing the X-Auth-Token token); for a cloud-managed network use Meraki (GET /organizations/{orgId}/devices, X-Cisco-Meraki-API-Key). Fetching is GET.
• Posting a message to Webex—send {"roomId": "...", "text": "..."} to POST /v1/messages. Creating something new means POST, with Bearer-token auth. Fetching a client list—Meraki's GET /networks/{networkId}/clients enumerates clients connected to a given network.
• The construction rule of thumb is the "verb -> HTTP method" mapping: read = GET / create/send = POST / replace = PUT / partial update = PATCH / delete = DELETE. The requirement's verb ("get" a list / "send" a message) is directly a cue for the method.

3.4.2Build-and-diagnose checklist

• Build steps: (1) confirm the correct endpoint and method in the API docs; (2) prepare auth (Meraki X-Cisco-Meraki-API-Key, Catalyst Center an X-Auth-Token obtained beforehand via POST /token, Webex Bearer); (3) call with requests and check resp.status_code and resp.json(); (4) handle pagination/rate limits. A missing auth header shows up as 401, and a wrong endpoint/method as 404/405.
• Diagnostic knack: reason backward from the response code. 401/403 = auth/permission (suspect the key/token or header name), 404 = wrong endpoint (URL or ID), 405 = method mismatch (e.g., POST to list), 429 = rate exceeded (back off / Retry-After). For someone else's bug too, isolate first from the returned status code.

Suppose you are asked to review a NOC-automation script that "fetches the list of connected clients on Meraki-managed store networks and notifies the count to a Webex space hourly." A colleague's code reads as follows. The client-fetch part is written as requests.post("https://api.meraki.com/api/v1/networks/L_123/clients"), and running it returns 405 Method Not Allowed. The cause is clear: fetching a list should be GET, but POST is used—a method mismatch (requests.get(...) is correct). Next, the header reads headers={"Authorization": "Bearer abc..."}, which is Webex's style; Meraki needs the API key passed in the X-Cisco-Meraki-API-Key header—left as is this yields 401 Unauthorized. Even after fixing method and auth, a non-existent network ID returns 404 and hitting the rate limit returns 429, so branch on resp.status_code and, on 429, wait per Retry-After. The later Webex notification, requests.post("https://webexapis.com/v1/messages", json={"roomId": room, "text": f"clients={n}"}, headers={"Authorization": f"Bearer {token}"}), correctly matches the requirement with send = POST and Bearer auth and is sound. The key points: the two APIs differ in auth-header style (Meraki = API-Key header, Webex = Bearer); the method is decided by whether the requirement's verb is "get (GET)" or "send (POST)"; and you fix bugs not by guessing but by reasoning backward from the status code (405 -> method, 401 -> auth, 404 -> endpoint/ID, 429 -> rate). Even a colleague's seemingly working code, read along these axes, lets you name "why 405, why 401" by the shortest path and correct it to the right GET plus the right header.

3.4.3Section summary

• Turn a requirement into "which platform, which endpoint, which verb -> HTTP method": device list = GET, Webex message = POST /v1/messages, client list = Meraki GET /networks/{id}/clients
• Auth style differs by platform: Meraki = API-Key header / Catalyst Center = X-Auth-Token / Webex = Bearer; mixing them up gives 401
• Diagnose faults by reasoning backward from the status code: 401/403 = auth, 404 = endpoint/ID, 405 = method mismatch, 429 = rate exceeded