🏆Capstone project: Project: The Reading List in FastAPI

Your app answers GET on both paths, writes books from a checked model, and runs its tests in process. Two behaviors of your Chapter 5 server are still missing: DELETE /books/{id}, and the limit query on GET /books. This project adds both, with two tests that notice when either one breaks. Every @app line and BookIn are already in reading_app.py; you write function bodies and tests.

What the app must do

• DELETE /books/{id} removes the book and answers 204 with no body. An unknown id gets 404, as everywhere else in the app.

• GET /books?limit=N answers with the first N books in id order, for N from 1 to 100. Without limit, it lists every book, and a limit larger than the number of books lists every book too.

204 with nothing

The line above delete_book is @app.delete("/books/{book_id}", status_code=204). A 204 says the request succeeded and there is nothing to send back. In Chapter 5 you built that reply by hand, with no body and no content-length. Here FastAPI sends it: whatever delete_book returns, the 204 goes out with no body and no content-length. On these versions it still carries content-type: application/json, a label with nothing to label, which is harmless. So the function’s job is the decision. Is there such a book? If not, raise the same HTTPException as get_book. If there is, remove it with .pop(), as your server’s delete_book did.

A query parameter FastAPI checks

Now read the rest of list_books’s def line:

def list_books(limit: int | None = Query(default=None, ge=1, le=100)):

Read it as you read book_id: int. FastAPI takes limit from the query string, turns it into an int, and checks that it is at least 1 (ge, greater than or equal) and at most 100 (le, less than or equal), all before your function runs. int | None with default=None means a request may leave it out, and then limit is None. So your function only ever meets None or a whole number from 1 to 100, and it needs no checks of its own.

FastAPI answers the rest itself, and not always as your server did:

• ?limit=0, ?limit=101, and ?limit=two get 422. Your server answered 400.

• ?limit= with nothing after it gets 422. Your server read an empty value as no limit and listed every book.

• ?limit=1&limit=2 gets 200 with two books: FastAPI keeps the last value of a repeated parameter. Your server refused the repeat with 400.

Milestones

1. delete_book, about four lines: the 404 for an unknown id, then .pop().

2. limit in list_books, about three changed lines: keep adding books while limit is None or the list is still shorter than limit.

3. Lesson 5’s two tests in tests/test_app.py, each with fresh_client(): test_delete_unknown_book_is_404 asserts that DELETE /books/99 answers 404, and test_limit_returns_the_first_books asserts that GET /books?limit=1 answers with exactly one book, book 1. A third test that deletes a book and then gets 404 when it asks for that book is worth adding.

Run the tests in the Shell tab:

python -m pytest -q

Every test should pass, and the summary line ends with 1 warning, the anyio notice from Lesson 2. If you like, run python pl_http.py uvicorn again: its three replies are the ones Lesson 4 showed.

Check my work sends requests through TestClient with books you have not seen, repeats the checks of Lessons 1 and 3, and checks DELETE, unknown ids on GET, PUT and DELETE, and limit. Then it runs your tests three times, as in Lesson 2: against your own app, where all must pass, and against two versions built from your functions with one mistake each, a delete_book that answers 204 for an unknown id and a list_books that ignores limit. One of your tests must fail against each.

The app beside your server

The app now matches your standard-library server on every behavior its functions decide: the statuses they choose, location, the stored books, 404 for an unknown id, and the limit slice. Where the two still differ, FastAPI decided, on the versions this course uses:

Changing those answers back would take code that catches FastAPI’s own errors, which this course does not ask you to write. Your tests record the ones that matter to you instead, and they will tell you if a new version of FastAPI changes one.

Press Check my work. One contract now has two implementations, and Chapter 12 returns to the one you built by hand: you finish it, finish its requests client, and prove that the two agree.