You are setting an interface description on an IOS XE router using Python requests and RESTCONF over HTTPS. The YANG path is ietf-interfaces:interfaces/interface=Loopback10, and the JSON payload must reach the exact resource, create it when it is missing, and use the RESTCONF JSON media type in both headers. Which requests call delivers the payload to the RESTCONF resource as required?
Select an answer to reveal the explanation.
Short Explanation
Every resource sits under the /restconf/data root, so you address the exact Loopback10 record instead of the whole list. PUT creates it when it is missing, and matching both headers to application/yang-data+json keeps the body in YANG JSON. It's the same as a parcel needing the full street address and the right postcode.
Full Explanation
RESTCONF addresses configuration as YANG resources, so the URL has to include the restconf/data root followed by the module and key path; that is what lands your payload on the Loopback10 record instead of the collection. PUT creates the target resource when it is missing and replaces it when it already exists, which is exactly the behavior your requirement describes, and the body is JSON nested in the module namespace. Both Content-Type and Accept must carry application/yang-data+json, because that media type identifies the RESTCONF JSON representation for the request and response. A PATCH-based edit is a normal way to change existing leaves, but a server must not create the target instance with PATCH, so it cannot create Loopback10. Sending application/json is the generic-JSON approach and does not use the media type your headers requirement calls for. Building the URL from the module path without the data segment does not address the RESTCONF resource. Exam caveat: a lab device may tolerate a laxer media type, but the RESTCONF contract is what the exam expects. Practical check: print resp.status_code, then GET the same URL and confirm the description came back.