A team is building a service that triggers work on a device instead of reading stored data: a single request names the action, carries its parameters, and returns the result. The lead asks which API style the design follows and which network automation example matches it. Which API style and matching example belong in the design note?
Select an answer to reveal the explanation.
Short Explanation
You can spot RPC when a request names an operation, supplies its parameters, and gets a result back; NETCONF rpc requests and gRPC service calls fit that pattern. RESTCONF GET reads a resource, while an event published to a topic has no direct reply, so those examples do not match the action described.
Full Explanation
RPC is defined by invocation: the caller names an operation, supplies its parameters, and the callee returns a result. NETCONF follows this model by wrapping an operation in an rpc request with a message ID and answering with an rpc-reply; gRPC service calls likewise invoke named operations with inputs and return results. REST instead uses a uniform interface in which a URL identifies a resource and standard methods read or change its representation. A RESTCONF GET that reads a YANG interface list therefore describes stored-data access, not the requested device action. Pairing REST style with that GET gives a resource-reading example rather than an action invocation, so it does not fit the design. Calling a RESTCONF GET an RPC also mismatches the correct RPC definition with an example that reads stored interface data. Event style publishes an action on a topic for later processing; because it provides no direct reply, it does not meet the requirement to return the result in the request-response exchange. Exam caveat: some REST APIs expose action endpoints that behave like RPC, so classify the interaction by whether it names an operation or addresses a resource. Practical check: inspect the request shape and ask whether its payload names a procedure to run.