A campus automation team must pull interface counters and push VLAN changes on IOS-XE switches using programmable interfaces. Scripts already use HTTPS with JSON payloads, and the team wants resource-oriented URIs with standard GET, PUT, PATCH, POST and DELETE operations against a YANG-defined datastore. Which RESTCONF characteristic design best matches the HTTPS and resource-model requirement?

The correct design is right because RESTCONF exposes YANG-defined datastores as HTTPS resource URIs manipulated with standard HTTP verbs, which meets the dual need to pull interface counters and push VLAN changes while reusing JSON over HTTPS tooling on IOS-XE. The NETCONF design fails by access model because although it provides full YANG-based automation for counters and VLANs and is widely used in campus networks, it uses SSH with XML RPC messaging rather than HTTPS with URI-addressed resources and GET, PUT, PATCH, POST and DELETE operations. The platform REST design fails by modeling because although it offers HTTPS transport with JSON payloads, resource URIs and HTTP methods routinely used for VLAN automation, it relies on device-specific resources rather than the required standards-based YANG datastore abstraction. The RESTCONF with XML design fails by payload fact because despite HTTPS transport, YANG-to-URI mapping and full operations for counters and VLANs, it standardizes on XML encoding while the stem states scripts already use JSON. An exam caveat is to separate what a protocol can support from what the scenario demands, since RESTCONF supports XML and JSON and read and write, but only the JSON-capable read-write design satisfies this stem. A practical check is to test authenticated GET on restconf/data for interfaces and PATCH with JSON for a test VLAN in a lab.