Admin API has no way to update just one field of a route

Nobody has started this yet — be first.

Business impact

Today, changing just one route's rate limit during an incident (turning it down because a client is hammering an upstream, say) means reconstructing and re-sending the entire route body from whatever the operator currently has on hand -- easy to get subtly wrong (drop a field by accident, revert someone else's more recent change to a different field) under exactly the time pressure where a small, targeted change is what is needed.

Problem

PUT /admin/routes/{id} exists and works, but it is a full replace: the caller has to send the entire RouteConfig body, including every field they do not want to change. There is now a PATCH /admin/routes/{id} endpoint too, but it is a stub -- it always responds 501 Not Implemented regardless of what is in the request body.

Current behavior

Calling PATCH /admin/routes/{id} with any body currently returns 501 Not Implemented -- patch_route's handler body has not been written yet.

Expected behavior

PATCH /admin/routes/{id} accepts a partial JSON body (any subset of RouteConfig's fields, e.g. just {"rate_limit": {"requests_per_second": 5, "burst": 10}}) and merges only those fields into the existing route, leaving everything else (auth, , , , etc.) untouched. It is effective immediately, same as , and still goes through the same breaker-config-consistency check as any other table mutation.

Steps to reproduce

pytest practice_tickets/tests/test_ticket_05_admin_patch_partial_update.py -v.
Or manually: PUT /admin/routes/foo to create a route, then PATCH /admin/routes/foo with {"rate_limit": {...}}.
Observe: 501 Not Implemented, regardless of the body sent.

Why this matters

The tricky part is not the top-level merge (route-level fields) so much as deciding what "merge" means for a nested field like rate_limit if the patch only sends part of it -- that behavior needs to be decided and documented rather than guessed implicitly, and it still has to flow through RouteTable's existing _check_breaker_config_consistency check exactly like PUT does, so a patch cannot sneak past the same consistency guarantee.

Suggested approach

Look at RouteConfig (a pydantic BaseModel) -- pydantic models have a documented pattern for producing an updated copy from a partial set of field overrides without touching the fields you do not mention. Decide explicitly how a partial rate_limit object should combine with the existing one before writing the merge.

Acceptance criteria

PATCH /admin/routes/{id} with {"rate_limit": {...}} changes only that route's rate limit; auth, timeouts, transform, etc. are unchanged from before the patch
PATCH /admin/routes/{id} for a route ID that does not exist returns 404
The result is immediately visible via GET /admin/routes/{id} and takes effect for the very next proxied request, no restart
A patch that would create a circuit_breaker mismatch with another route sharing the same upstream is rejected (409), same as PUT

Verification

pytest practice_tickets/tests/test_ticket_05_admin_patch_partial_update.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b feat/admin-patch-partial-update

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin feat/admin-patch-partial-update

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Dynamic API Gateway & Reverse Proxy

A FastAPI reverse proxy that streams every request and response without ever buffering a body in full, with hot-reloadable routing, per-route auth, Redis token-bucket rate limiting, and a per-upstream circuit breaker.

Fork on GitHub

Download

Setup

Dynamic API Gateway & Reverse Proxy

git clone <your-fork>
cd FastAPIDevTraining/gateway_proxy
cp .env.example .env   # adjust GATEWAY_ADMIN_TOKEN etc. if you like
docker compose up --build   # Redis + the gateway (uvicorn --reload) + 2 demo upstreams

The gateway is reachable at . Two demo upstreams come up alongside it — (low-latency JSON echo at , plus for the streaming-passthrough demo) and (, , for timeout and circuit-breaker demos) — and wires five example routes against them, one per feature. Verify the stack with (liveness only) and (pings Redis, which every rate-limited route depends on). Every endpoint (route CRUD, reload, persist, breaker snapshot) requires .