Using the path operation function name as the operationId¶
If you want to use your APIs' function names as operationIds, you can iterate over all of them and override each path operation'soperation_id using their APIRoute.name.
You should do it after adding all your path operations.
fromfastapiimportFastAPIfromfastapi.routingimportAPIRouteapp=FastAPI()@app.get("/items/")asyncdefread_items():return[{"item_id":"Foo"}]defuse_route_names_as_operation_ids(app:FastAPI)->None:""" Simplify operation IDs so that generated API clients have simpler function names. Should be called only after all routes have been added. """forrouteinapp.routes:ifisinstance(route,APIRoute):route.operation_id=route.name# in this case, 'read_items'use_route_names_as_operation_ids(app)
Tip
If you manually call app.openapi(), you should update the operationIds before that.
Warning
If you do this, you have to make sure each one of your path operation functions has a unique name.
Even if they are in different modules (Python files).
To exclude a path operation from the generated OpenAPI schema (and thus, from the automatic documentation systems), use the parameter include_in_schema and set it to False:
You can limit the lines used from the docstring of a path operation function for OpenAPI.
Adding an \f (an escaped "form feed" character) causes FastAPI to truncate the output used for OpenAPI at this point.
It won't show up in the documentation, but other tools (such as Sphinx) will be able to use the rest.
fromtypingimportSet,UnionfromfastapiimportFastAPIfrompydanticimportBaseModelapp=FastAPI()classItem(BaseModel):name:strdescription:Union[str,None]=Noneprice:floattax:Union[float,None]=Nonetags:Set[str]=set()@app.post("/items/",response_model=Item,summary="Create an item")asyncdefcreate_item(item:Item):""" Create an item with all the information: - **name**: each item must have a name - **description**: a long description - **price**: required - **tax**: if the item doesn't have tax, you can omit this - **tags**: a set of unique tag strings for this item \f :param item: User input. """returnitem
When you declare a path operation in your application, FastAPI automatically generates the relevant metadata about that path operation to be included in the OpenAPI schema.
The dictionary in openapi_extra will be deeply merged with the automatically generated OpenAPI schema for the path operation.
So, you could add additional data to the automatically generated schema.
For example, you could decide to read and validate the request with your own code, without using the automatic features of FastAPI with Pydantic, but you could still want to define the request in the OpenAPI schema.
You could do that with openapi_extra:
fromfastapiimportFastAPI,Requestapp=FastAPI()defmagic_data_reader(raw_body:bytes):return{"size":len(raw_body),"content":{"name":"Maaaagic","price":42,"description":"Just kiddin', no magic here. ✨",},}@app.post("/items/",openapi_extra={"requestBody":{"content":{"application/json":{"schema":{"required":["name","price"],"type":"object","properties":{"name":{"type":"string"},"price":{"type":"number"},"description":{"type":"string"},},}}},"required":True,},},)asyncdefcreate_item(request:Request):raw_body=awaitrequest.body()data=magic_data_reader(raw_body)returndata
In this example, we didn't declare any Pydantic model. In fact, the request body is not even parsed as JSON, it is read directly as bytes, and the function magic_data_reader() would be in charge of parsing it in some way.
Nevertheless, we can declare the expected schema for the request body.
Using this same trick, you could use a Pydantic model to define the JSON Schema that is then included in the custom OpenAPI schema section for the path operation.
And you could do this even if the data type in the request is not JSON.
For example, in this application we don't use FastAPI's integrated functionality to extract the JSON Schema from Pydantic models nor the automatic validation for JSON. In fact, we are declaring the request content type as YAML, not JSON:
In Pydantic version 1 the method to get the JSON Schema for a model was called Item.schema(), in Pydantic version 2, the method is called Item.model_json_schema().
Nevertheless, although we are not using the default integrated functionality, we are still using a Pydantic model to manually generate the JSON Schema for the data that we want to receive in YAML.
Then we use the request directly, and extract the body as bytes. This means that FastAPI won't even try to parse the request payload as JSON.
And then in our code, we parse that YAML content directly, and then we are again using the same Pydantic model to validate the YAML content:
In Pydantic version 1 the method to parse and validate an object was Item.parse_obj(), in Pydantic version 2, the method is called Item.model_validate().
Tip
Here we reuse the same Pydantic model.
But the same way, we could have validated it in some other way.