A team is designing a Python client for routers that support both NETCONF and RESTCONF. For actions like committing a candidate configuration, the engineer wants the client to name a specific operation, send parameters to it, and receive a reply produced by that operation. Which API style should the design use to model these action calls?
Select an answer to reveal the explanation.
Short Explanation
RPC-style APIs suit action calls: you name the job, hand over the inputs, and get one answer back. It's like phoning in a takeout order instead of browsing a menu, because you state exactly what you want. The key idea is that the operation is invoked by name rather than addressed as stored data.
Full Explanation
In an RPC-style API the client builds a message that names a single operation and carries that operation's parameters, and the server returns a reply generated for that specific call. That fits an action such as committing a candidate configuration, because the outcome depends on the operation itself rather than on the state of a stored object; NETCONF edit-config and close-session messages are classic examples of NETCONF RPC operations. The REST style is generally resource-oriented: it addresses a resource and applies an HTTP method, rather than expressing the call as a named operation with an argument list. RESTCONF can also expose YANG-defined RPC operations and actions, typically invoked with POST, but a PUT to a datastore resource is not a commit operation. A gNMI subscription stream is for receiving updates, not for invoking a named operation and receiving its matching reply; gNMI also has Get and Set RPCs, so the stream alone is not representative of all gNMI calls. Exam caveat: reason about the message pattern, not the transport, since both patterns can ride on HTTP or gRPC. Practical check: if you can point at an operation name in the request and expect one matching reply, you are looking at RPC.