APIs and REST for Network Engineers
Making a Safe GET Request
What you'll learn
- pip install requests — this module's one new dependency
- How to make a GET request and read its status code
- Why GET is the safe, read-only default, the same discipline as send_command()
- How this lesson's mock API stands in for a real device or controller
Listen to a guided explanation of this lesson.
Spoken narration isn't supported in this browser.
requests: this curriculum's fourth external package
Same pattern as Netmiko, Jinja2, and ansible-core
Each of those was a learner-side Python package, installed with pip, never added to this website's own code. requests is no different.
pip install requestsWorks the same on Windows, macOS, or Linux — unlike ansible-core, requests has no platform-specific requirements for the basic usage this module teaches.
Your first real GET request
import requests
response = requests.get("http://127.0.0.1:8765/devices/SW1/interfaces")
print(response.status_code)
print(response.json())requests.get(url) sends the request and waits for the response. .status_code is the HTTP status code; .json() parses the response body (covered fully in Lesson 3).
Running this against this module's mock API (standing in for a real device or controller — see the callout below) prints:
200
{'hostname': 'SW1', 'interfaces': [{'name': 'GigabitEthernet1/0/1', 'status': 'up'}, {'name': 'GigabitEthernet1/0/2', 'status': 'down'}]}200 means the request succeeded. The body is SW1's interfaces — the exact same kind of fact send_command('show ip interface brief') would have returned as raw text, now arriving as structured JSON instead.
The mock API in this module
Every example in this module runs against a small, deterministic local API standing in for a real device or controller's interface — built with nothing but Python's own standard library. It exists so every request/response mechanic in this module is something you can genuinely run and inspect, not just read about. It is not something this module teaches you to build; the skill this module teaches is being an API client, not an API author.
Status codes: the first thing to check
200 OK — the request succeeded
404 Not Found — nothing at this URL
401 Unauthorized — missing or invalid credentials
500 Server Error — something broke on the server's sideA three-digit number that always arrives with a response. 2xx generally means success; 4xx means the client's request was the problem; 5xx means the server's side was the problem. Lesson 5 covers this in depth — for now, the habit that matters is checking it before trusting anything else in the response.
GET is the read-only default
GET asks a question; it never changes anything. This is exactly the same discipline "Running Show Commands with Netmiko" and Ansible's ad-hoc commands both established: read first, always, before anything that could change a device's state.
Key takeaways
- requests is this curriculum's fourth external package — pip install requests, learner-side only, never part of this website's own code.
- requests.get(url) sends a GET request; .status_code and .json() read the response.
- This module's mock API is real, deterministic, stdlib-only infrastructure for practicing — not something this module teaches you to build.
- A status code arrives with every response and is the first thing worth checking — 2xx success, 4xx client-side problem, 5xx server-side problem.
- GET is read-only by convention, the same discipline as send_command() — it never changes the target, which is exactly why it's always the safe default.