APIs and REST for Network Engineers
What Is an API? HTTP for Network Engineers
What you'll learn
- The HTTP client/server request-response model
- Why this is a new transport, not a replacement for SSH/CLI automation
- Where RESTCONF fits as a real, standardized network-specific example
- That this module extends the same automation lineage, one transport later
Listen to a guided explanation of this lesson.
Spoken narration isn't supported in this browser.
A new transport, not a new idea
Every automation tool this curriculum has built — Netmiko, Ansible — assumes a device that speaks CLI over SSH. That assumption is still completely valid; nothing in this module retires it. But a large and growing share of real infrastructure — cloud-managed switches, SD-WAN controllers, DNA Center, Meraki, ACI, and RESTCONF-enabled IOS-XE devices — exposes its primary programmatic interface as an HTTP API, not a CLI. This module is about that second transport.
- Clientyour Python script
- HTTP requesta method, a URL, sometimes a body
- APIthe controller or device's HTTP interface
- HTTP responsea status code, headers, and usually a JSON body
That's the entire model: a client sends a request, a server sends back a response. No persistent session the way an SSH connection is one — each request stands alone.
Positioned against what you already know
- One persistent SSH sessionconnect, run commands, disconnect
- Output is textmeant for a human terminal
- The device itself is the target
- Independent requestsno persistent session
- Output is usually JSONmeant for a program
- A controller often sits in front of many devices
Both are real, both are current
This isn't a story of one replacing the other. A classic Cisco IOS switch you SSH into is automated exactly as well with Netmiko or Ansible as it ever was. A cloud-managed platform that only exposes an HTTP API needs this module's skills instead — because there's no CLI to SSH into at all. Which tool you reach for depends on what the target actually offers, not on which is newer.
Where RESTCONF fits
One real, standardized example is worth naming now, even though it isn't this module's main path: RESTCONF (RFC 8040) is an HTTP-based API that many Cisco IOS-XE devices and other platforms expose directly — the same request/response model this lesson just described, applied straight to a network device instead of a general-purpose controller. This module's main path uses a simpler, easier-to-practice API shape throughout; RESTCONF reappears briefly in the capstone (Lesson 7) as a concrete, real network example — not as a second curriculum to learn alongside this one.
What this module actually builds
- Python automationPhase 2.6
- Netmiko (SSH)Phase 2.7
- Reliable AutomationPhase 2.8
- Jinja2 configuration templatesPhase 2.9
- Ansible orchestrationPhase 3.0
- REST API automationthis module
Every one of those modules taught a way to reach a device or a config outcome. This one adds a transport for the systems where SSH was never an option to begin with — the same lineage, one more tool in it.
Key takeaways
- HTTP's client/server model: a client sends a request (method + URL, sometimes a body), a server sends back a response (status code + usually JSON) — no persistent session, unlike SSH.
- This is a new transport for systems that expose an HTTP API, not a replacement for SSH/CLI automation on systems that expose a CLI.
- RESTCONF (RFC 8040) is a real, standardized example of this exact model applied to network devices — named now, developed further only in the capstone, never a second curriculum inside this module.
- This module continues the same lineage from Phase 2.6 through Phase 3.0 — one more transport, not a reset.