A Python script uses the requests library to push interface settings over RESTCONF to several IOS XE devices, and some replies arrive as 204 No Content while others return 400 with a YANG error body. The audit log must judge every edit correctly. Which status-code and error-body interpretation rule should the script follow?
Select an answer to reveal the explanation.
Short Explanation
A 204 is like a receipt with no note: your edit still succeeded, even though there’s no response body. If you get a 400, check the ietf-restconf:errors body, using error-tag to classify the failure and error-path, when present, to pinpoint the affected node.
Full Explanation
A 204 No Content response indicates that the edit succeeded; RESTCONF does not need to return a representation of the updated resource. For a 400 response, the YANG error body supplies details that the HTTP status alone cannot: error-path, when present, identifies the relevant node, while error-tag categorizes the failure. Using error-message to identify the node is unreliable because it is explanatory text, not a substitute for the structured error-path, and its wording can vary. Using error-message to classify the failure is similarly brittle; the standardized error-tag is the appropriate field for that purpose. Treating a 204 as pending until a follow-up GET confirms the configuration also misinterprets the successful response. Read-after-write verification can be useful operationally, but replication, caching, or timing may affect what the GET shows without changing the meaning of the 204. Exam caveat: an empty response does not mean no change, and optional YANG error fields may not all be present. Practical check: test the audit logic with a 204 and with 400 bodies that include, omit, or vary error-path; ensure it records 204 as success and uses error-tag for classification when supplied.