RESTCONF authentication works, but a request for an interface returns 404. Changing passwords is unlikely to explain a resource that cannot be found. The next useful evidence is the model supported by the device and the path leading to the requested list entry.
Lab status: This is a proposed exercise, not a completed device test or client case study. Code examples require validation against your image and dependency versions. My documented background is NOC/data center operations, multi-vendor Netmiko workflows and Python/Flask integration.
Offline example checks: October 20, 2026: the added helper/demo block executed with local fixtures, and related negative cases were checked offline. No live device, controller, fabric or service behavior was validated.
Which YANG path errors can produce RESTCONF 404?
Module names, container hierarchy, list keys and resource existence all matter. An example based on one IOS XE release is not a universal path for every Cisco product. Operational state and configuration can also live under different models. Identify the actual data you need before constructing a URL.
Probe the approved RESTCONF base resource and one documented known-good leaf before a deep list path. An HTML 404 at the base suggests service/path/platform mismatch; a YANG error on a specific instance suggests a model or key investigation. A 404 by itself does not distinguish all of these cases.
Why do interface list keys need URL encoding?
The native model may use GigabitEthernet=0%2F0%2F2, while another model uses the full interface name as a key. Encode the key once with quote(value, safe=''); encoding an already encoded key produces %252F. Confirm the model’s key definition rather than swapping path fragments between models.
| Observation | Next check |
|---|---|
| Every path fails | API endpoint, access and RESTCONF support |
| Parent succeeds, child fails | List key and entry existence |
| Same URL works on another release | Module/revision differences |
| JSON arrives but refers to another interface | Resource identity and key construction |
Proposed IOS XE lab: check supported models and resource paths
Record model availability and the exact interface identifier from a trusted source on the image. Test a known existing list entry and one intentionally absent entry. Keep authentication and TLS settings fixed so a path experiment does not become an access-policy experiment.
Python: URL-encode an interface list key
The additional helper constructs an ietf-interfaces list path only when that model is available. It does not prove that IOS XE implements this model on every release. Use the same authenticated Session and response inspector as the RESTCONF 401 guide to distinguish structured-resource errors from an unexpected web response.
from urllib.parse import quote
# Example for an IOS XE native interface list; confirm the model first.
interface_key = '0/0/2'
encoded_key = quote(interface_key, safe='')
path = ('/restconf/data/Cisco-IOS-XE-native:native/'
'interface/GigabitEthernet=' + encoded_key)
print(path)
Worked Python example and input contract
from urllib.parse import quote
def interface_path(name):
if not isinstance(name, str) or not name or any(c in name for c in '\r\n'):
raise ValueError('invalid_interface_key')
return '/restconf/data/ietf-interfaces:interfaces/interface=' + quote(name, safe='')
print(interface_path('GigabitEthernet0/0/2')) # Model-specific synthetic key
How do interface identity and physical state affect the check?
An interface may exist while administratively or operationally down. That is different from a missing list instance. A hardware replacement may change numbering; compare the collected inventory and interface identity before interpreting a 404 as a physical link failure.
Should you query a vendor-native or standard YANG model?
Choose by supported operational/configuration fields and stable key semantics. Put each model behind a separately reviewed adapter. A native configuration leaf cannot be replaced with an operational state leaf without changing what the dashboard claims.
How should you verify the resource and scope an integration?
Verify the returned object’s identity and expected fields, then test missing instance and unsupported model branches. Mark schema or model coverage as unknown when evidence is incomplete. Do not suppress 404 responses by dropping the device from reports.
Related troubleshooting and implementation
Explore the network automation troubleshooting collection to connect this issue to adjacent workflows. The Netmiko, NETCONF and RESTCONF comparison helps when you are choosing an interface rather than fixing an existing implementation.