An airport authority needs a Python script that reads interface operational state from IOS XE over HTTPS using JSON or XML without opening a NETCONF SSH session. Which approach fits that tooling model?
Select an answer to reveal the explanation.
Short Explanation
Picture RESTCONF as a web API for the switch—same HTTPS habits your civic scripts already know. You ask for interface oper data with the right Accept header and get JSON or XML back. No need to stand up a full NETCONF SSH client just to read status.
Full Explanation
Airport authority scripts that must read IOS XE interface operational state over HTTPS using JSON or XML without opening a NETCONF SSH session should use RESTCONF with appropriate Accept/Content-Type headers against the YANG data store. RESTCONF provides request/response model-driven access over HTTPS, which matches tooling that prefers web APIs over NETCONF SSH. Oper state resources are exposed through the same modeling approach when the platform supports them.
Polling every interface with classic SNMP GETBULK ignores the model-driven HTTPS path the question asks for. Scraping show interfaces via Expect over Telnet because RESTCONF supposedly cannot expose oper state is outdated and insecure. Enabling only gRPC dial-out telemetry and parsing GPB without any request/response API solves streaming use cases but not on-demand HTTPS reads.
Exam caveat: RESTCONF paths and JSON/XML encodings must match the YANG module; oper vs config resources differ. Operational check: GET a known interface oper resource via RESTCONF in lab with JSON Accept, verify fields against show commands, then automate with certificate-based HTTPS. Record API versions used by the airport platform team. Record the chosen control and rejected alternatives in the municipal change record so future on-call engineers understand the failure modes avoided for city services.