Build API and UI endpoints for browsing, searching, and filtering extracted experiments.
Researchers should be able to find all experiments related to a gene, compare results
across studies, and trace evidence chains from experiments to hypotheses.
GET /api/experiments — List experiments with filtering (type, entity, disease, replication_status)GET /api/experiments/{id} — Full experiment detail with provenance linksGET /api/experiments/entity/{name} — All experiments mentioning an entityGET /api/experiments/hypothesis/{id} — Experiments supporting/contradicting a hypothesisGET /experiments — HTML browse page with faceted searchGET /experiment/{id} — Detail page showing structured results, statistics, provenanceatl-ex-04-QUAL — Quality scores needed for sorting/filteringatl-ex-03-LINK — Entity links needed for entity-based queries/api/experiments/priority-queue was being matched by the generic detail route because @app.get("/api/experiments/{experiment_id}") appeared too early in api.pypriority-queue and entity lookups@app.get("/api/experiments/{experiment_id}") below the specific experiment browse/search routes so one-segment static paths dispatch correctlytests/test_experiment_api_route_order.py to assert priority-queue, entity/{name}, and detail routes resolve to the intended handlerspytest -q tests/test_experiment_api_route_order.py (3 passed) and python3 -m py_compile api.py tests/test_experiment_api_route_order.pyreplication_status filter on /api/experiments list and new JSON endpoints for detail/entity/hypothesis queriesreplication_status filter to GET /api/experiments (JSON) + included field in responseGET /api/experiments/{experiment_id} detail endpoint with debates, results, linked hypotheses, prerequisites, blocks, wiki pagesGET /api/experiments/entity/{entity_name} endpoint for entity-based queries (direct + via hypothesis links)GET /api/experiments/hypothesis/{hypothesis_id} endpoint for hypothesis-linked experimentsreplication_status dropdown filter to /experiments HTML browse pagePrior review blocked on route ordering: the generic
/api/experiments/{experiment_id} handler was placed before the specific
sub-routes, causing FastAPI to match paths like /api/experiments/priority-queue
as experiment_id="priority-queue" and return 404.
Verification: Confirmed the current route order is correct — all specific
sub-routes (priority-queue, entity/{name}, hypothesis/{id}, replication/{entity})
are declared BEFORE the catch-all {experiment_id} handler (lines 11465–11826 vs
11538). This was already correct in commit 7126e6c31; the prior review apparently
misread the file state.
Regression test added: tests/test_experiment_routes.py — four smoke tests
that call each sub-route and assert status != 404 (or in the hypothesis case,
allow 404 for non-existent IDs). Documents the ordering constraint explicitly.
Rebase: Synced worktree to latest origin/main (0f46acefa) via git stash &&.
git rebase origin/main
Route order check on HEAD (post-rebase):
11465 GET /api/experiments
11539 GET /api/experiments/entity/{entity_name}
11609 GET /api/experiments/hypothesis/{hypothesis_id}
11658 GET /api/experiments/priority-queue
11704 GET /api/experiments/replication/{entity}
11745 GET /api/experiments/{experiment_id} ← catch-all after specific routesSpecific routes are correctly declared before the catch-all. tests/test_experiment_routes.py
and tests/test_experiment_api_route_order.py cover the ordering constraint from both HTTP
and router-dispatch perspectives.
entity, hypothesis, priority-queue, and replicationapi.py comment documenting the route-order invariant next to @app.get("/api/experiments/{experiment_id}")tests/test_experiment_api_route_order.py with an explicit replication-path dispatch assertion so the static route family is fully covered