Network automation lab 4 of 27
HTTP and REST with RESTCONF: curl, status codes and Python requests
Take a real router's REST API apart with curl: the HTTP request and response, authentication, media types, URLs built from YANG, every write method and its status code, a request that fails three different ways, and an RPC, then read it all from Python with requests.
Run this lab
It needs Lite: its 2 nodes are set to 2 vCPU and 5,120 MB in total. That fits the free demo too.
In your workspace: Shared, then Network Automation - CCNA and CCNP Automation guided labs, then 04 - HTTP and REST with RESTCONF - curl status codes and Python requests
- Level
- Beginner
- Time
- About 70 minutes
- Nodes need
- 2 vCPU, 5,120 MB
- Smallest plan
- Lite
The scenario
Kestrel Freight's developers want to build a self-service portal that reads and changes router settings. Before they write any code, they need someone on the network team who understands the router's REST API inside out: what a request really looks like on the wire, which header picks the data format, how a URL is built, which status code means what, and how to read an error. That's you, and the API is RESTCONF on the IOS XE router xe1.
| Device | Address | API |
|---|---|---|
| devbox | 10.10.20.10/24 | curl, Python 3 with requests |
| xe1 | 10.10.20.21/24 (Gi1) | RESTCONF at https://xe1/restconf (HTTPS, port 443), self-signed certificate |
What you’ll practise
- Identify the parts of an HTTP request and response (method, URL, headers, status code, body)
- Authenticate with HTTP Basic and choose JSON or XML with the Accept and Content-Type headers
- Construct RESTCONF URLs for containers, list entries and leaves, with query parameters
- Use GET, POST, PUT, PATCH and DELETE and explain the codes 200, 201, 204, 400, 401, 404 and 409
- Troubleshoot failed requests from the status code, the error body and the documentation, and call a REST API from Python
The tasks
- Look at one request and response in full
- Authenticate, and see what Basic really sends
- Choose the format with Accept
- Build URLs from the data model
- Call the API from Python
- Use every write method and learn its status code
- Troubleshoot three failing requests
- RPCs on a REST API, and saving
The Lab Tasks pane has the scenario, these tasks, the checks to run, hints and the full solution.
Topology and devices
The network as it opens in EVE-NG, drawn from the lab’s own canvas, and the image each node runs.
Every link, as text
- devbox
eth0to Mgmt (network) - xe1
Gi1to Mgmt (network)
| Node | Device | Image in Add Node | Set to |
|---|---|---|---|
| devbox | EVE-NG GUI server (Docker) | eve-gui-server:latest | 1 vCPU, 1,024 MB |
| xe1 | Cisco CSR 1000v | csr1000vng-universalk9.17.03.08a-serial | 1 vCPU, 4,096 MB |
How to open this lab
Sign in to your workspace at
lab.cloudlabbox.com.In File Manager, open Shared, then the folder
Network Automation - CCNA and CCNP Automation guided labs.Open
04 - HTTP and REST with RESTCONF - curl status codes and Python requestsand start its nodes, then open Lab Tasks for the scenario and the steps.
The lab is read-only. You can start the nodes and configure the devices, but changes to the topology can’t be saved. To change it, rebuild it in your own folder.
More Network automation labs
Related labs in other courses
CloudLabBox is independent of Cisco. The lab follows exam topics and isn’t vendor training material; vendor names identify the exams and the images in the workspace.