In this exercise, you will create the back-end API for the simple check-in system began in EX01. In the next exercise, you will work with a partner to connect this functionality with the front-end.

Getting Started

1. Accept the assignment on GitHub: https://classroom.github.com/a/HB9DifCC
2. Clone and setup the VSCode development environment according to the README.md file in the repository.

Workflow Expectations

For this exercise, you should work on appropriately scoped work-in-progress feature branches you push to GitHub as progress is made.

Overview

The goal of this exercise is to achieve a similar outcome to EX01 in terms of functionality, except that the focus is on the back-end REST API powered by FastAPI.

The starting point for this exercise backtracks on EX01. Before you begin working on this project, you should complete the accompanying reading as pre-work. This guided reading takes you on a tour through the code base and narrows in on important aspects to help you understand how the backend starter code comes together.

You are encouraged to keep your implementation as straightforward as possible.

While the stories are the same as before, there are a few specific technical requirements to lookout for on the implementation side. We will be looking more closely at some implementation details on this exercise.

Technical Requirements

1. 10pts - Story D API. Implement the route to create a checkin for Story D. It should be a POST and expects a CheckinRequest model object as its request body, as defined in backend/models/checkin.py. With a successful checkin, the route should respond with a Checkin object. Use the provided back-end storage service methods for creating the checkin. If there is an error, respond with a status code of 422. Validate your implementation using FastAPI’s OpenAPI localhost:8000/docs tool.

2. 10pts - Story E API. Implement the route to list all checkins for Story E. Validate your implementation using the OpenAPI /docs tool.

3. 10pts - In order to implement the back-end of Story F, deleting a registered user, you will need to extend the functionality of backend/services/storage.py and test your extensions. Testing expectations are covered in the next requirement. Intentionally choose meaningful names for all method(s), variable(s), and other identifier(s) used in order to add delete registration functionality to your storage service. Your documentation conventions should follow those established in the starter files.

4. 10pts - You must also implement unit tests for the prior requirement in backend/test/services/storage_test.py.

To run your unit tests, you have two options:

A. From a new terminal, change your directory to backend and try running pytest.

B. Alternatively, use VSCode’s built-in Testing tool in the sidebar. Note that from this panel you can press the debug run on individual tests and set breakpoints in your own code.

Write tests that prove/verify your delete functionality is working in the storage service layer before worrying about its route in the following requirement. You should have one test per feature of the expected case(s) and one per edge case. As a rule of thumb, you can interpret “one test per feature of the expected case(s)”, as making assertings against one object or one collection per unit test. This hueristic helps you be sure your tests are granular and help simplify the source of potential regressions in the future.

5. 10pts - Once you are convinced your storage implementation is working, add a route using the DELETE method to your API and test that it works via the FastAPI /docs explorer. Your route path should use the following convention: /api/registrations/$PID where $PID is a registered user’s 9-digit PID. If no user exists with this PID, respond with status code 404. Verify this API route works via the OpenAPI /docs tool.

Stories

Story B

As Sol Student, I want to register for the CS Experience Lab on my first visit to the colab space so that I can easily check-in in the future. (The API for this Story is already implemented in the starter code.)

Story C

As Merritt Manager, I want to be able to see a listing of all registered members. (The API for this Story is already implemented in the starter code.)

Story D

As Arden Ambassador, I want to be able to check Sol Student in using only thier PID so that I can easily check them in.

Story E

As Merritt Manager, I want to be able to see a listing of all checkins.

Story F

As Merritt Manager, I want to be able to delete registered users and their associated checkins from the system.

Submission Instructions

Submission instructions for EX03 coming soon.