Post Request in FastAPI | What is Request Body? | Video 5 | CampusX

FastAPI’s “create” flow hinges on one practical idea: accept a POST request with a request body, validate it automatically with a Pydantic model, then merge the new resource into the JSON-backed “database” only if the incoming patient ID doesn’t already exist. That combination—POST + request body + Pydantic validation + server-side persistence—turns a messy, manual validation task into a structured endpoint that also generates clean interactive documentation.

After a quick recap of the patient-management project (CRUD-style operations with endpoints for listing, retrieving by patient ID via a path parameter, and sorting via query parameters), the focus shifts to creating new patients. The “create” endpoint uses an HTTP POST method because the client is sending new data to the server rather than requesting data. Along with the POST request, the client sends patient details in a JSON request body—fields like name, gender, city, age, height, and weight. In FastAPI terms, that payload is the request body: the portion of an HTTP request that carries structured data from client to server, commonly used with methods like POST and PUT.

The core engineering work starts with building a Pydantic model for the incoming payload. The model defines required fields and adds constraints and metadata so both validation and documentation improve. The transcript walks through creating a Patient model that includes an ID (as a string), name and city (strings), age (integer with a range constraint), gender (restricted to allowed literal options such as male/female/others), and height/weight (floats constrained to be greater than zero). Descriptions and examples are added using typing annotations so the auto-generated docs show meaningful guidance.

Two additional fields—BMI and verdict—are not expected from the client. Instead, they’re computed automatically using Pydantic computed fields. BMI is calculated from weight divided by height squared, rounded to two decimals. Verdict is derived from BMI thresholds (underweight, normal, overweight, obese) using conditional logic. Because computed fields depend on other validated inputs, they’re triggered automatically once the model has the required height and weight.

With the model ready, the create endpoint is implemented as an app.post route at /create. The endpoint function receives the request body as a Patient Pydantic object, meaning validation happens before the endpoint logic runs. The server then loads existing patient data from the JSON file, checks whether the incoming patient ID already exists, and if it does, raises an HTTP 400 error (“patient already exists”). If the ID is new, the endpoint merges the new patient into the existing dictionary—converting the Pydantic object to a dict while excluding the ID from the value portion—then saves the updated structure back to the JSON file.

Finally, the endpoint is tested through FastAPI’s interactive docs. Submitting an existing ID returns 400, while submitting a new ID returns a 200 success response. The created record shows that BMI and verdict were computed server-side automatically, confirming that Pydantic handled both validation and derived-field logic without requiring the client to send those fields. The next steps are queued for update and delete endpoints.