When you build an API with FastAPI, almost everything you do boils down to answering one question: how does the client want to talk to me? HTTP gives us several ways to have that conversation, but two verbs — GET and POST — handle the vast majority of real-world traffic. Understanding how FastAPI treats each of them is the first real milestone in learning the framework.

This article walks through what GET and POST mean, how FastAPI implements them, and how to decide which one to use.

The Core Idea: Reading vs. Doing

Before touching any code, it helps to internalize the philosophy behind these two methods:

1. GET is for reading. You're asking the server for information, and you expect that asking doesn't change anything.

2. POST is for doing. You're sending the server data so it can create, process, or change something.

This distinction isn't just a style preference — it's baked into the HTTP specification. GET requests are supposed to be safe (no side effects) and idempotent (calling it 100 times has the same effect as calling it once). POST requests carry no such guarantee.

Setting Up

A minimal FastAPI app needs just a few lines:

python

from fastapi import FastAPI

app = FastAPI()

Run it with uvicorn main:app --reload, and you're ready to define routes.

GET: Asking for Data

A GET endpoint in FastAPI is about as simple as it gets. You decorate a function with @app.get(), and FastAPI handles the rest.

python

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str | None = None):
    return {"item_id": item_id, "q": q}

Two things are happening here that make FastAPI pleasant to work with:

1. Path parameters — item_id comes straight from the URL, e.g. /items/42. Because you typed it as int, FastAPI automatically validates and converts it. Send /items/abc and you'll get a clean 422 error instead of a crash.

2. Query parameters — q isn't part of the path, so FastAPI treats it as an optional query string parameter, e.g. /items/42?q=search-term.

GET requests don't have a request body (technically they can, but it's discouraged and poorly supported by many clients/proxies). So anything the client needs to send has to go in the URL — as path segments or query parameters. This is why GET is best suited for fetching, filtering, and searching, not for sending complex or sensitive data.

POST: Sending Data

POST requests are built for carrying a payload. In FastAPI, that payload is almost always defined using Pydantic models, which give you validation, parsing, and auto-generated documentation for free.

python

from pydantic import BaseModel

class Item(BaseModel):
    name: str
    price: float
    is_offer: bool | None = None

@app.post("/items/")
def create_item(item: Item):
    return {"name": item.name, "price": item.price}

Here, FastAPI looks at the type hint Item, recognizes it as a Pydantic model, and knows to parse the JSON request body into it. If the client sends malformed data — say, price as a string that can't convert to a float — FastAPI rejects it automatically with a descriptive error message.

This is where FastAPI really shines compared to older frameworks: you get body parsing, type coercion, and validation in a single, readable function signature.

Combining Path, Query, and Body Parameters

Real endpoints often need a mix of everything:

python

@app.post("/items/{item_id}")
def update_item(item_id: int, item: Item, notify: bool = False):
    return {"item_id": item_id, "item": item, "notify": notify}

FastAPI is smart about sorting these out:

1. item_id is in the path, so it's a path parameter.

2. item is a Pydantic model, so it's parsed from the request body.

3. notify is a plain type with a default value and isn't in the path, so it becomes a query parameter.

No extra configuration needed — FastAPI infers the source of each parameter from its type and position.

Automatic Documentation

One detail that surprises newcomers: as soon as you define these routes, FastAPI generates interactive documentation for free. Visit /docs and you'll see a Swagger UI where you can try out both the GET and POST endpoints directly in the browser, complete with example request bodies for your Pydantic models. Visit /redoc for a cleaner, read-only reference view.

Choosing the Right One

A simple rule of thumb: if the client is asking for something, use GET. If the client is sending something that should be stored, processed, or acted upon, use POST. Trying to force a search form with ten filters into GET query parameters gets messy fast — that's often a sign POST (or a request body) is the better fit. Conversely, using POST for something like "get user by ID" throws away caching, breaks browser back-button behavior, and confuses anyone consuming your API.

Wrapping Up

FastAPI's design encourages you to think in terms of what shape of data goes where — path, query, or body — and lets Python's own type hints do the heavy lifting for validation and documentation. GET and POST are the two verbs you'll reach for constantly, and once their roles click, the rest of FastAPI's routing system (PUT, DELETE, PATCH, and beyond) feels like a natural extension of the same idea.