Python FastAPI Tutorial (Part 4): Pydantic Schemas - Request and Response Validation

FastAPI’s request/response validation becomes concrete once Pydantic schemas define the API contract—what clients must send and what the server will return. By adding three Pydantic models (shared fields, create payload, and response payload) and wiring them into endpoint decorators, the API gains runtime enforcement of field constraints, automatic 422 error responses for bad input, and documentation that lists exact field types and validation rules.

The tutorial starts by addressing a gap in the existing endpoints: they return plain dictionaries with no schema, so the interactive docs don’t show response structure, and there’s no safe way to create posts through the API. Pydantic is introduced as the validation layer built into FastAPI (installed automatically as a dependency). Unlike “type hints as documentation only,” Pydantic uses those type hints at runtime to validate incoming data and generate detailed error messages when data doesn’t match.

A new schemas.py file is created to centralize the contract. A PostBase model inherits from BaseModel and defines shared fields for title, content, and author. Field constraints are added using Field—title requires a minimum length of 1 and a maximum length of 100 characters; content requires at least 1 character; author requires at least 1 and at most 50 characters. Separate models then clarify intent: PostCreate inherits from PostBase to represent what clients send when creating a post, while PostResponse inherits from PostBase and adds server-generated fields like id (integer) and date_posted (string for now). PostResponse also sets model configuration with config dict using from_attributes=True, which prepares the schemas to read data from attribute-based objects (important once a database layer replaces in-memory dictionaries).

With schemas in place, main.py is updated to import PostCreate and PostResponse. The GET endpoints gain response_model annotations: the “list posts” route returns a list of PostResponse objects, and the “single post” route returns one PostResponse. These response models do more than improve docs—they validate outgoing data and filter out extra fields, helping prevent accidental data leakage.

A new POST /posts endpoint is added with response_model=PostResponse and status_code=201. FastAPI uses the PostCreate type hint to parse and validate the JSON body before the endpoint function runs. If validation fails, the client receives a 422 response with specific details. When validation succeeds, the handler generates an id, constructs a post dictionary from the validated fields, appends it to the in-memory list, and returns the new post.

Testing in the interactive docs confirms the behavior: successful creation returns a 201 with id and date_posted; missing required fields triggers 422 errors; and constraint violations (like too-short strings) produce precise messages. Finally, the tutorial highlights a practical limitation: created posts vanish after a server restart because they’re stored in a Python list in memory. Persistent storage requires a database, which is slated for the next tutorial.

Overall, the key takeaway is that Pydantic schemas define the API contract and enable FastAPI to handle validation, serialization, and documentation consistently—before introducing database-backed persistence and relationships.