Issue getting body params without using pydantic model

I’ve followed the instructions in #895 and in the docs but I must be doing something silly because this doesn’t work:

@router.post("/posts", tags=["posts"], status_code=201)
async def create_post(url: str = Body(...)):
    print(url)
    return []

It returns {"detail":[{"loc":["body","url"],"msg":"str type expected","type":"type_error.str"}]}

with the body { "url": "hello there" }

but the following works using a pydantic model:

class CreatePost(BaseModel):
    url: str


@router.post("/posts", tags=["posts"], status_code=201)
async def create_post(body: CreatePost):
    print(body.url)
    return []

Any ideas?

[gautamsinghania95]

Short answer: Adding embed=True to url will work

@router.post("/posts", tags=["posts"], status_code=201)
async def create_post(url: str = Body(..., embed=True)):
    print(url)
    return []

Long answer:

• With only one variable as the Body, FastAPI thinks of that as describing the whole body
• In the first scenario, with url as the only Body variable, FastAPI thought of it as describing the whole Body structure
• Since it was a string, a map failed
• In the body, instead of { "url": "hello there" }, if you passed "hello there", it would have worked
• In the second scenario, with body as the only Body variable, FastAPI thought of it as describing the whole Body structure
• Since it was a Pydantic BaseModel, a map worked

@tiangolo I have a view that the default should be other way round. To have only one variable describe the whole body structure, we must have a flag like whole_body=True added.

[tiangolo]

Thanks @gautamsinghania95 for the suggestion, but I would expect that for most of the use cases people would use a single variable expecting it to be the top body. And having to add additional code to make it work like that would end up being quite cumbersome.

I agree that the fact that it behaves differently with respect to one specific parameter depending on if there are other body parameters or not is not ideal, but here’s one of those points where I would trade the simplicity for most use cases in exchange of a little inconsistency for these corner cases.

And either way, both options are achievable with embed=True.

On the other hand, changing the default behavior would break many live apps, for not a very big improvement. So I think I’ll leave it as it is.