# Exercise 2: Refactor a Legacy RPC-Style API into Proper REST Resources

## Scenario

You've inherited the following endpoint list from a legacy internal service. It "works," but it was designed RPC-style (Richardson Maturity Level 0/1 — see the REST Fundamentals topic) and is now being opened up to external partners, who expect a resource-oriented API.

```
POST /getUserOrders          body: { userId: 7 }
POST /createNewOrderForUser  body: { userId: 7, items: [...] }
POST /cancelOrderById        body: { orderId: 482 }
GET  /orderDetails?id=482
POST /updateOrderItems       body: { orderId: 482, items: [...] }
POST /deleteOrder            body: { orderId: 482 }
GET  /getAllOrderItemsForOrder?orderId=482
POST /addItemToOrder         body: { orderId: 482, sku: "SKU-1", qty: 2 }
POST /removeItemFromOrder    body: { orderId: 482, itemId: 9 }
GET  /searchOrdersByStatus?status=pending
```

## Deliverables

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

1. **A before/after table** — columns: Old endpoint | New Method + URI | HTTP status code(s) it should return | Reasoning. One row per legacy endpoint above.
2. **Explicit handling of `/searchOrdersByStatus`** — explain how this becomes a filter rather than its own endpoint (this connects to the Pagination/Filtering/Sorting/Searching topic — describe the query parameter you'd use, even though full filtering design is out of scope here).
3. **A note on backward compatibility** — the legacy endpoints are still used internally by another team's job scheduler. Propose one concrete strategy for exposing the new REST design without breaking that consumer on day one (this should reference ideas you'd expect the API Versioning topic to cover — a short paragraph is enough, not a full versioning spec).
4. **Identify any endpoint above whose correct REST status code depends on idempotency** — call out which of the old endpoints, if retried by a flaky client, could cause duplicate side effects under the *old* design, and confirm your new design's HTTP method choice fixes or doesn't fix that (referencing the safe/idempotent method properties from the HTTP Methods and Status Codes topic).