Courts developers prefer creating VLANs on campus switches through an HTTP-style API that uses YANG data models rather than NETCONF XML RPCs. Which interface matches that preference?
Select an answer to reveal the explanation.
Short Explanation
You can think of RESTCONF as YANG with a web-API accent: HTTP verbs operate on modeled resources. If you prefer GET, PUT, or PATCH to NETCONF RPC envelopes, this is the interface that fits.
Full Explanation
RESTCONF matches the preference because it exposes YANG-modeled resources through HTTP/HTTPS-style operations, including GET, POST, PUT, PATCH, and DELETE, with JSON or XML encodings. That supports developer-centric VLAN creation without requiring NETCONF XML RPC tooling. RSPAN destination ports advertised via HTTP GET only fail by concept: RSPAN is a mirroring technology, not a YANG configuration API for creating VLANs. HSRP hellos encoded as JSON for VLAN creation describe a nonexistent control-plane mechanism; HSRP provides first-hop redundancy, not VLAN provisioning. Flexible NetFlow exporters send flow records, so they confuse flow export with RESTCONF resource operations and do not configure VLANs through YANG over HTTP. Exam caveat: RESTCONF and NETCONF differ in transport and style, but both can manage YANG-modeled features such as VLANs when the platform’s models support them. Prefer RESTCONF when the question stresses HTTP-style APIs and developer-oriented JSON/XML resource operations. Practical check: enable RESTCONF securely with HTTPS and authentication, POST or PUT the VLAN resource according to its YANG model, then GET it to confirm creation and verify that the VLAN appears in the switch’s operational state.