Recipe API — Relational Modeling, Not JSON-in-a-Column

GET /recipes needs pagination

GET /recipes currently returns every single recipe row, every time, with every ingredient and step nested in -- no limit. That's fine with a handful of seed recipes; it's a real problem the day this product has real content. A recipe site with 50,000 recipes turns every GET /recipes call into a multi-megabyte response with joined ingredient/step data for rows the client will never render. That's slow responses, wasted bandwidth (worse for anyone on mobile data), and unnecessary load on the database and API process for a page that only ever shows the user 20-50 recipes at a time. This is the single highest-leverage change for keeping the API fast as the content library grows, and it's the kind of thing that's cheap to add now and increasingly disruptive to retrofit later (client code that assumed a bare array has to change no matter when this lands).

Ingredient search silently became case-sensitive

GET /recipes/search?ingredient=... is the primary way a user finds recipes by what's in their fridge -- "what can I make with chicken?" It's documented as case-insensitive (README.md's endpoint table says exactly that), and until recently it was. Now, any query whose capitalization doesn't happen to match how the ingredient was originally typed into the database returns zero results -- not an error, just an empty, unhelpful list. Since most real users type search terms in lowercase or Title Case without checking how any given recipe author capitalized "Chicken Breast" vs "chicken breast," this silently breaks the feature for the majority of real-world queries while looking, to an automated smoke test that happens to match case, like it still works fine.

GET /recipes needs configurable sorting

Right now every GET /recipes response comes back sorted by id -- i.e. by insertion order -- no matter what the caller wants. A frontend that wants to show "quickest recipes first" or "newest recipes first" currently has to fetch everything and sort client-side, which defeats the purpose of filtering/paginating on the server and means every client re-implements sorting logic the API should own. It's a small gap, but it's the kind of missing, obviously-expected capability that makes an API feel unfinished to anyone integrating against it.

Add POST /recipes/:id/duplicate (clone a recipe)

Recipe authors constantly want to start a new recipe from an existing one -- a "Chicken Stir Fry" variant that swaps the protein, a smaller/larger batch with tweaked steps, a seasonal remix. Today the only way to do that through this API is to GET the original, hand-copy every field (including every ingredient and every step) into a new POST /recipes body, and resubmit. That's tedious and error-prone by hand, and it means any client wanting a "duplicate this recipe" button has to reimplement the copy logic itself instead of the server owning it. A one-call duplicate endpoint is a small addition with an outsized quality-of-life payoff for anyone actually authoring content through this API.

A failed recipe update can wipe out the recipe's data anyway

This is the worst class of bug an API can ship: the request the user made failed (they got an error back, or at least not a success), and yet their data is gone anyway. A recipe author tries to update a recipe, makes a mistake in the payload that the database rejects, gets back a failure -- and when they go look at the recipe afterward, it now has zero ingredients and zero steps. There is no error message telling them this happened, no undo, and nothing in the API's response hints at it -- the failed request looks like it just... failed, while quietly deleting everything. For anything resembling production data, this is the kind of bug that turns into an incident: support tickets from users insisting "I didn't touch it, it just disappeared," with no audit trail pointing back to the failed PUT that actually did it.