Flask API learning path

Authenticate with REST Client

Open the Flask backend in VS Code and select the local REST Client environment. Reuse the existing api/user_auth.http file: choose Send Request and supply your own UID and password through its prompts. Never commit real passwords, cookies, or tokens.

That request sends POST /api/authenticate. REST Client remembers response cookies by default for later requests to the same host. Authenticate again after switching environments. The backend’s HTML /login route is a separate interface, not the JSON authentication endpoint.

In an .http file inside the same backend repository, send:

### Current identity - authenticate in user_auth.http first
GET {{baseUrl}}/api/id
Accept: application/json

Inspect the response status and identity. An authentication failure is not a user-model failure: first determine which boundary rejected the request.

Read api/user.py

Find user_api, its /api prefix, and the registrations for /authenticate, /id, and /user. Locate _Security, _ID, and _CRUD, then inspect the method that handles your request. Read decorators and validation before following the successful path.

Record the contract for one operation: method and path, required inputs, authentication, success shape/status, and failure behavior. Do not assume a successful create uses 201 just because another API does.

Follow model/user.py

Find where the handler imports and uses User from model.user. For your chosen method, identify the lookup or model operation, what arguments it receives, and how its returned data becomes an HTTP response. Distinguish authentication logic, API validation, and persistence responsibilities.

The purpose here is to follow the call boundary, not redesign the user schema. Detailed model fields, relationships, SQL queries, migrations, and transaction behavior will be taught separately.

Inspect the Existing CRUD Request File

Read api/user_crud.http with your teacher before running its sequence. It documents create, identity, list, update, and delete requests. The full sequence requires an Admin account and a disposable UID that does not already exist. Set kasm_server_needed to false unless you deliberately intend to request server provisioning.

Send one request at a time and inspect its result. Stop if Create fails; do not update or delete an account you did not successfully create for this test. The identity request returns the signed-in Admin, not the newly created user. Delete expects 204 No Content: do not attempt to parse a JSON body from it. Use local or explicitly authorized test records, not production accounts.

These are manual checks, not an automated test suite. A failed request is evidence to compare with the source code, not a reason to disable security.

Trace and Debug

Set a breakpoint in the selected API method, send the REST Client request, inspect its inputs, and step into the model operation. Continue execution before expecting a response. When integrating a frontend, compare its Network request with the working REST Client request; direct requests do not test browser CORS behavior.

Explain one successful path and one expected failure using the code and response as evidence. Continue with the Microblog API.