What is the difference between a path parameter and a query parameter?

WHAT THIS TESTS: This question checks whether you know how REST URLs separate resource identity from filtering, and whether you understand FastAPIs automatic binding convention. Path parameters locate a specific resource inside the URL hierarchy, while query parameters supply modifiers like search terms or pagination. The interviewer wants to see that you can declare both in a single endpoint without confusion.

A GOOD ANSWER COVERS: First, the conceptual split: path parameters belong to the route template because they identify a resource, such as a user, and changing them changes the resource you are addressing. Query parameters are optional key-value pairs that appear after the question mark and are used for filtering, sorting, or searching. Second, the FastAPI mechanics: you write the path parameter inside curly braces in the decorator, like @app.get("/users/{user_id}/items"), and you name the function argument identically so FastAPI can inject it. Any function argument that is not declared in the path is automatically interpreted as a query parameter. Third, optionality: to make q optional you give it a default of None, such as q: str | None = None. If you omit a default, FastAPI treats the parameter as required and the client must supply it in the query string.

COMMON WRONG ANSWERS: A red flag is putting user_id in the query string, for example /users/items?user_id=1, because that breaks RESTful hierarchy and caching expectations. Another mistake is defining q inside the path template, like /users/{user_id}/items/{q}, which turns a search filter into a pseudo-resource. Some candidates also forget to set a default value for q, which makes it a required query parameter instead of an optional search term. Finally, confusing the order of arguments or claiming that FastAPI requires explicit Query declarations for basic optional parameters shows a lack of familiarity with the framework.

LIKELY FOLLOW-UPS: The interviewer may ask how you would validate the query parameter, perhaps by adding a min length or regex. They might also ask what happens if user_id is not an integer, or how you would make q required in a different endpoint. You could also be asked to contrast query parameters with request bodies for complex search filters.

ONE CONCRETE EXAMPLE: You could write from fastapi import FastAPI and then app = FastAPI(). Then define @app.get("/users/{user_id}/items") followed by async def read_items(user_id: int, q: str | None = None). Inside the function you can return a dictionary containing the user_id and q values. When a client calls /users/5/items?q=foo, FastAPI extracts 5 as the integer user_id and foo as the optional query string q.