You are designing an API that allows a consumer to tetch all orders associated to a given customer You want to use a RESTful design Which design…

The most appropriate RESTful design is GET /customers/{customer-id}/orders. This approach correctly models the hierarchical relationship where 'orders' are a sub-collection or a nested resource belonging to a specific 'customer'. It uses the GET method, which is the standard, safe, and idempotent HTTP verb for retrieving resources. The URI path is resource-oriented, using nouns (customers, orders) to clearly identify the resources, which is a core principle of RESTful API design. This structure is intuitive and clearly expresses the intent to fetch all orders for a particular customer.

B. GET /orders?customer-id={customer-id}

This is a valid RESTful pattern for filtering a top-level resource collection, but it's less expressive of the direct parent-child relationship than option A, which is the preferred pattern for nested resources.

C. GET /getOrdersForCustomer?customer-id={customer-id}

This URI includes a verb ("getOrdersForCustomer"), which is characteristic of an RPC-style (Remote Procedure Call) design, not a resource-oriented RESTful design. REST URIs should represent nouns (resources).

D. POST /orders with a post-body of customer-id-{customer-id}

This uses the POST method, which is incorrect for a retrieval operation. POST is used for creating new resources or for actions that are not safe or idempotent. Using it to fetch data violates fundamental REST principles.

---

1. Google Cloud

API Design Guide

"Resource Names": The guide specifies a hierarchical structure for nested resources. It states

"If a resource contains a sub-resource

the sub-resource can be exposed using sub-collections." An example provided is users/{uid}/settings

which is analogous to the correct answer customers/{customer-id}/orders. This directly supports modeling orders as a sub-collection of a customer.

Source: Google Cloud. (n.d.). Resource Names. API Design Guide. Retrieved from https://cloud.google.com/apis/design/resourcenames#collectionname

2. Google Cloud

API Design Guide

"Standard Methods": This document defines the semantics for standard HTTP methods. It explicitly states that the GET method "gets a resource." This supports the use of GET for fetching data and invalidates option D

which incorrectly uses POST.

Source: Google Cloud. (n.d.). Standard Methods. API Design Guide. Retrieved from https://cloud.google.com/apis/design/standardmethods#get

3. Apigee

"Web API Design: The Missing Link" E-book: This official Apigee publication emphasizes resource-oriented design. In Chapter 2

"It's All About the Nouns

" it advises

"Good APIs are simple to use because they are resource-oriented. Their resources are typically nouns..." This principle invalidates option C

which uses a verb-based path (getOrdersForCustomer).

Source: Raj

K.

& Anglin

B. (2012). Web API Design: The Missing Link. Apigee. (Chapter 2

"It's All About the Nouns").