Fastapi: [QUESTION] A way to handle multiple request content types

[dmig-alarstudios]

OpenAPI allows describing multiple accepted content-types for a request.
Is it possible via FastAPI means?

I'd like to make a password login endpoint accepting both application/json and application/x-www-form-urlencoded using a single handler.

[tiangolo]

A single request can read a JSON body or (exclusive or) form data. That doesn't depend on FastAPI but more on how the web (HTTP) works.

So there's no straightforward way to do it using the same normal methods.

Nevertheless, you can access the request object directly, and extract the information from it by hand: https://fastapi.tiangolo.com/advanced/using-request-directly/

[dmig-alarstudios]

Mmm... sorry for inaccuracy, I mean to define two content-types somehow, to see them in acceptable types in /docs and to be able to test.

[phy25]

Reference: https://swagger.io/docs/specification/describing-request-body/

[Sharathmk99]

@phy25 Is it possible to achieve multiple request body for same endpoint?

[evstratbg]

@phy25 Is it possible to achieve multiple request body for same endpoint?

yes, but you should decode it by yourself. Small example below:

@router.post('/sync', description=PIPELINE_DESCR) async def sync_pipeline( reset_cache: bool, cache_key: bool, file: bytes = File(...), pipeline: bytes = File(...) ): pipeline = json.loads(pipeline) file_bytes = io.BytesIO(file)

[Sharathmk99]

@evstratbg In this approach, content-type will be multipart-formdata right?
We are looking multiple content-type/request body.

[evstratbg]

@evstratbg In this approach, content-type will be multipart-formdata right?
We are looking multiple content-type/request body.

Yes
Multiple content type of a body is not possible. It's not limitations of a framework, it's a limitation of the http protocol

[Sharathmk99]

@evstratbg there is no limitations like that in http protocol. I have implemented in other frameworks like flask, spring, etc.. OpenAPI spec also supports multiple content type for one endpoint.

[evstratbg]

@evstratbg there is no limitations like that in http protocol. I have implemented in other frameworks like flask, spring, etc.. OpenAPI spec also supports multiple content type for one endpoint.

Using multipart? Can you post a small example of what you implemented?

[Sharathmk99]

Not using multipart. I use content-type to accept application/json or application/xml or application/pdf... I'll try to post you same with other framework. Thank you

[macleodmac]

Hi,

I'm also interested in being able to define a single route that can consume either:

• application/json request
• application/x-www-form-urlencoded request
  ...using a single handler.

At the moment, the only way I can see to do this is to get the raw request, inspect the content-type and then handle it accordingly.

[tiangolo]

Thanks for the help here everyone! :rocket:

Yeah, the way to support different content types on the same _path operation_ would be to read the request directly and parse it depending on the content type.

But then you have to do the data validation and documentation in OpenAPI yourself, in your code.

There wouldn't be an easy way to do it more automatically based on type annotations as the body has to be consumed from the ASGI messages, and it would be a different process for each media type.

What I would try to do is to have a different path for each media type, that way I can enforce validation for the JSON or form data while reading the content directly for other complex types.

[github-actions[bot]]

Assuming the original issue was solved, it will be automatically closed now. But feel free to add more comments or create new issues.

[erny]

I have a similar problem when integrating third party backends like filebrowser.org. In Django REST Framework Content Negotiation is accomplished using "Renderers", i.e. a way to convert the response to different output languages.

[erny]

Finally I used my own simple media renderers which do a simplistic approach to process the "Accept" header and return a response on given renders (json, xml, plain text)