# Exercise 1: Classify Changes as Breaking or Non-Breaking

## Instructions

For each of the 12 proposed changes below, write, in this file, below this line:

1. **Breaking** or **Non-breaking**, using the test from theory section 1 ("could a client written against the old contract, with reasonable-but-not-paranoid parsing, keep working unmodified?").
2. A one-sentence justification.
3. If breaking, name which versioning mechanism (section 2–6) you'd reach for to ship it, and why that one over the alternatives.

## The current contract

```
GET /v1/products/{id}

200 OK
{
  "id": 501,
  "name": "Trail Runner 3",
  "price": 89.99,
  "in_stock": true,
  "tags": ["shoes", "running"]
}
```

## The 12 proposed changes

1. Add a new field `"currency": "USD"` alongside `price`.
2. Change `"price": 89.99` to `"price": { "amount": 8999, "currency": "USD" }`.
3. Rename `in_stock` to `available`.
4. Add a new optional query parameter `?fields=id,name` to request a sparse fieldset.
5. Change the default page size of `GET /v1/products` from 50 to 20.
6. Add `"rating"` as a new possible value that can appear inside the existing `tags` array.
7. Start returning `404` instead of `200` with `{"in_stock": false, "deleted": true}` for a product that was deleted.
8. Add a required `Idempotency-Key` header to `POST /v1/products`.
9. Change validation so that `name` (previously max 200 chars) now allows up to 500 chars.
10. Change validation so that `price` (previously any positive number) must now be a multiple of 0.01.
11. Add a brand-new endpoint `GET /v1/products/{id}/reviews`.
12. Reorder the fields in the JSON response object (e.g. `name` now appears before `id`).

## Deliverable

A numbered list, 1–12, each with: classification, justification, and (for breaking changes only) your chosen versioning mechanism with a one-sentence "why this one." For at least one change, explicitly note whether your answer would change if you knew a large fraction of clients use strict/schema-validated deserialization (referencing theory section 9's point on strict clients) — and say which change and why.
