# Exercise 1: Design the Resource Model for a Food Delivery Platform

## Scenario

You're designing the public API for a food delivery platform, `FastPlate`. Product has described the domain:

- **Restaurants** have a name, address, and a **menu** made of **menu items** (name, price, category).
- **Customers** place **orders**. An order belongs to one customer, references one restaurant, and contains a list of **order items** (a menu item id + quantity, snapshotted at order time).
- An order moves through a **status** lifecycle: `pending -> confirmed -> preparing -> out_for_delivery -> delivered`, or it can be `cancelled` from `pending` or `confirmed` only.
- Customers can leave one **review** (rating 1-5 + text) per completed order.
- A courier can be **assigned** to an order once it's `confirmed`, and can mark it `picked_up` and `delivered`.

## Deliverables

Produce all of the following, in this file, below this line:

1. **A table of every resource and its URI pattern** — columns: Resource name | Collection URI | Item URI | Notes. Cover restaurants, menu items, orders, order items, reviews, and courier assignment.
2. **Nesting decisions with justification** — for each resource, state whether it is nested under a parent or promoted to top-level, and explain *why* using the depth/embedding guidance from the theory file (section 3).
3. **A table of non-CRUD actions** — list every operation in the scenario that doesn't map cleanly to plain CRUD (e.g. cancelling an order, assigning a courier, marking picked up/delivered) as a Method + URI pair, using the controller sub-resource pattern from theory section 4. Justify each choice over a plain `PATCH` field flip.
5. **One example request/response pair** — pick any single endpoint from your design and write out a full realistic HTTP request and its JSON response body, including status code.

## Constraints

- Every URI you propose must obey the naming rules in the theory file (plural nouns, no verbs, consistent casing).
- State clearly which fields are embedded vs. linked when an order response includes restaurant/customer data, and why.
- Do not exceed 2 levels of nesting anywhere — if your natural design would need more, explain how you flattened it (per section 3's "promote to top-level" guidance).