200-901 Question #416: Real Exam Question with Answer & Explanation

Question

Drag and Drop Question Drag and drop the characteristics from the left onto the corresponding categories on the right to compare RESTful and RPC APIs. Answer:

Explanation

This drag-and-drop question tests the understanding of key characteristics differentiating RESTful and RPC API architectural styles, including their statefulness and protocol usage.

Approach. To correctly answer this question based on the provided solution, the test-taker must drag the following items:

• 'stateless' to the 'RESTful' category: RESTful APIs are fundamentally stateless; each request from client to server must contain all information needed to understand the request, and the server must not store client context between requests.
• 'sometimes uses HTTP' to the 'RESTful' category: While RESTful APIs are overwhelmingly implemented over HTTP in practice, REST is an architectural style that, in its purest definition, is theoretically protocol-agnostic. Thus, from a strict theoretical viewpoint, it 'sometimes uses HTTP' rather than being strictly mandated.
• 'session-based' to the 'RPC' category: RPC (Remote Procedure Call) architectures can often involve stateful interactions where server-side sessions might be maintained to preserve context across multiple calls from a client.
• 'must use HTTP' to the 'RPC' category: This pairing is less intuitive for general RPC, but when considering modern high-performance RPC frameworks like gRPC, they mandate HTTP/2 as their underlying transport protocol. In the context of exam questions comparing these styles, this option might refer to such specific, prevalent implementations.

Common mistakes.

• common_mistake. A common mistake would be to interchange the HTTP-related characteristics, assigning 'must use HTTP' to RESTful and 'sometimes uses HTTP' to RPC. While REST is strongly associated with HTTP in common practice and RPC can utilize various protocols, the specific phrasing 'must use HTTP' for RPC (referring to modern gRPC implementations on HTTP/2) and 'sometimes uses HTTP' for REST (emphasizing its theoretical protocol-agnosticism) is what the provided solution implies. Swapping 'stateless' and 'session-based' would also be a fundamental error, as statelessness is a core principle of REST, and session-based interactions are more characteristic of RPC.

Concept tested. The underlying technical concept being tested is the understanding of the fundamental characteristics and architectural principles of RESTful (Representational State Transfer) and RPC (Remote Procedure Call) APIs, specifically regarding their statefulness (stateless vs. session-based) and their typical or mandatory protocol usage (HTTP-centric vs. flexible transport).

No community discussion yet for this question.