Task 1: The Application and Its Repository

Until Task 3 you work on main itself: one commit per route, pushed as you go.

1. Write one route and its tests, and run the tests.

2. Commit it, and push. Add the files by name, the ones this commit is about, never git add .: it would sweep in whatever else lies in the directory, a .venv/ or a __pycache__/.

   1$ git status
   2$ git add app/main.py tests/test_books.py
   3$ git commit -m "Add POST /books"
   4$ git push
   

3. Go on to the next route.

You split the routes, each writes theirs on a branch of their own, and each merges their branch into main by hand. No pull requests yet: they come with Task 3.

1. Write the common part together, at one keyboard: the app, the storage and the checks of the book's fields, which every route uses. Push it to main.

2. Split the routes into two GitHub issues, each assigned to one of you, each route with its tests:

   • issue #1, Student A: POST /books, GET /books and GET /books/<id>;
   • issue #2, Student B: PUT /books/<id>, DELETE /books/<id> and GET /healthz.

3. Each works on a branch named for the issue, as The Plan names them: feature/1-create-and-read and feature/2-update-and-delete.

   1$ git switch main
   2$ git pull
   3$ git switch -c feature/1-create-and-read
   

4. Commit as you go, and push the branch, so your partner can see it.

   • Add the files by name, never git add .: it would sweep in whatever else lies in the directory.
   • Keep your tests in a file of your own, tests/test_create_read.py or tests/test_update_delete.py, so the two of you change only one file in common.

   1$ git status
   2$ git add app/main.py tests/test_create_read.py
   3$ git commit -m "Add POST /books"
   4$ git push -u origin feature/1-create-and-read
   

5. Merge into main when your routes and their tests pass:

   1$ git switch main
   2$ git pull
   3$ git merge feature/1-create-and-read
   4$ git push
   

   • The first to merge finds main unchanged since step 1: git moves main forward, with no conflict.

6. The second to merge runs the same commands, and git pull brings the partner's routes first.

   • Both of you added routes in the same file, so git merge may stop with a conflict there.
   • Open the file, keep both sides' routes, and delete the conflict markers (<<<<<<<, =======, >>>>>>>).
   • Run every test, both students', then mark the file resolved by adding it, finish the merge and push:

   1$ git add app/main.py
   2$ git commit
   3$ git push
   

7. Both pull main, and run the tests: each now has the whole API.

• If git push to main is refused because your partner pushed first, run git pull, then push again.

• A route is a plain function per method and path.
• The checks of the field table are yours to write: Flask hands you the parsed JSON and nothing more.
• Flask answers 422 only when you return it, with the error body, from your own checks.
• A body that is not JSON makes Flask answer 400 by itself: read the body in the mode that returns nothing instead, and answer 422.

• The book is a Pydantic model: the field table, written as types and limits.
• FastAPI checks each body against the model and answers 422 by itself.
  • A body that is not JSON is a 422 as well.
  • Its error body is {"detail": [...]}, listing every failing field; keep it.
• A missing book is yours to answer: raise FastAPI's HTTP exception with 404.
• The model also draws the OpenAPI page, at /docs: try every route there.