Drag and Drop Question Drag and drop the API characteristics from the left onto the categories on the right. Answer:

Question

Exhibit

Answer Area

Explanation

This question tests the ability to distinguish between the core characteristics of REST and RPC API architectural styles by correctly assigning descriptive statements to their respective categories.

Approach. The correct interaction involves dragging each characteristic to its appropriate API style category. Here's the breakdown and reasoning:

1. 'It follows a resource-oriented model.' should be dragged to REST. REST (Representational State Transfer) is fundamentally based on the concept of resources, which are identified by URIs and manipulated using standard HTTP methods (GET, POST, PUT, DELETE). RPC, conversely, is procedure-oriented.

2. 'The API can be stateless.' should be dragged to REST. Statelessness is a core constraint of REST, meaning each request from the client to the server must contain all the information needed to understand the request, and the server does not store any client context between requests. While RPC can be stateless, it is a defining architectural constraint for REST.

3. 'The API is seen as a function call.' should be dragged to RPC. RPC (Remote Procedure Call) is an architectural style that allows a client to execute a procedure or function in a remote address space as if it were a local call. This is the defining characteristic of RPC.

4. 'There is communication between server and client.' should be dragged to RPC. While this statement is true for virtually all distributed API interactions, including REST, in the context of these specific choices and the defining features, it aligns more with the RPC model's emphasis on a direct 'call' and 'response' mechanism between a client and a server's procedure. For REST, statelessness and resource-orientation are more distinct defining characteristics. Given the need to fill both slots for RPC, and 'The API is seen as a function call.' being explicitly RPC, this general communication aspect rounds out the RPC characteristics provided in this specific question's context.

Common mistakes.

• common_mistake. A common mistake would be to confuse the core principles of REST and RPC. For example, placing 'It follows a resource-oriented model.' under RPC would be incorrect because RPC is procedure-oriented, not resource-oriented. Similarly, assigning 'The API is seen as a function call.' to REST would be wrong as REST interacts with resources via HTTP methods, not by directly calling functions. Placing 'The API can be stateless.' under RPC might seem plausible as RPC can be stateless, but statelessness is a fundamental architectural constraint for REST, making it a more defining characteristic for REST in this comparison. Placing 'There is communication between server and client.' under REST might also seem correct because REST also involves client-server communication, but in the context of distinguishing between the two given the other options, it serves better to fill the RPC characteristics when the 'function call' aspect is the primary identifier.

Concept tested. Distinguishing between REST (Representational State Transfer) and RPC (Remote Procedure Call) API architectural styles, specifically their core characteristics, such as resource-orientation vs. function calls, and statelessness.

No community discussion yet for this question.