NetAuto Academy

Intermediate Lab

Auditing a REST API Interface Report

Intermediate25 min

Objective

Evaluate a captured JSON API response against two independent conditions and produce a per-device compliance verdict naming exactly what's wrong.

Builds on APIs and REST for Network Engineers.

Prerequisites

  • Comfortable reading nested JSON/dict structures (Reading Structured JSON Responses)
  • Comfortable with list comprehensions and set operations
Local/offline only. The JSON below is a fixed sample response, not a live API call -- no request, endpoint, or token of any kind is used.

Scenario

The problem

"Reading Structured JSON Responses" taught you how to pull fields out of a response.json() dict. This lab picks up right after that call returns: given the interface data it hands you, which interfaces actually need attention? Two independent conditions matter here -- an interface that should be up but isn't, and one running hot enough to be a capacity risk -- and a device can have either, both, or neither.

Starter data

starter.py
API_RESPONSE = {
  "interfaces": [
      {"device": "RTR1", "name": "Gi0/1", "adminStatus": "up", "operStatus": "up", "utilizationPercent": 12},
      {"device": "RTR1", "name": "Gi0/2", "adminStatus": "up", "operStatus": "down", "utilizationPercent": 0},
      {"device": "RTR2", "name": "Gi0/1", "adminStatus": "up", "operStatus": "up", "utilizationPercent": 94},
      {"device": "RTR2", "name": "Gi0/2", "adminStatus": "down", "operStatus": "down", "utilizationPercent": 0},
      {"device": "RTR3", "name": "Gi0/1", "adminStatus": "up", "operStatus": "up", "utilizationPercent": 30},
  ]
}

UTILIZATION_THRESHOLD = 90

Fixed sample data written for this lab, shaped the way a real interface-status API would return it (camelCase keys, one flat list) -- not captured from any live endpoint.

Task

Write two filter functions:

  • find_should_be_up(interfaces) — interfaces where adminStatus == "up" but operStatus == "down".
  • find_high_utilization(interfaces, threshold=UTILIZATION_THRESHOLD) — interfaces above the threshold.

Then write build_device_verdicts(api_response) that returns one dict keyed by device name, each value {"compliant": bool, "issues": [...]}. Every issue entry should name the interface and which problem(s) it has (an interface can have both problems at once). A device with zero issues should have "compliant": True and an empty "issues" list.

Hints

Expected output

expected output
RTR1: {'compliant': False, 'issues': [{'interface': 'Gi0/2', 'problems': ['should_be_up']}]}
RTR2: {'compliant': False, 'issues': [{'interface': 'Gi0/1', 'problems': ['high_utilization']}]}
RTR3: {'compliant': True, 'issues': []}

Real, verified output. Three devices, three different outcomes -- two distinct failure reasons and one genuinely clean device, all from the same run.

Validation checklist

Self-check only -- nothing here is submitted or graded. Compare against your own output manually.

Solution

Solution

Try the task yourself first -- the full solution and explanation stay hidden until you click above.

Key takeaways

  • A device can fail zero, one, or both checks at once -- the report structure has to hold a list of problems per interface, not a single flag.
  • setdefault() is what keeps a fully compliant device visible in the report instead of silently absent.
  • This is fixed, offline sample JSON -- no live API request, endpoint, or token was used.

Related lessons

Reading Structured JSON Responses

The exact response.json() -> nested dict/list shape this lab's API_RESPONSE stands in for.

Read lesson

Done with this lesson?