Codecov Report

Base:100.00% // Head:100.00% // No change to project coverage 👍

Coverage data is based on head(685f402) compared to base(cf73051).
Patch coverage: 100.00% of modified lines in pull request are covered.

❗ Current head685f402 differs from pull request most recent headfe9c95c. Consider uploading reports for the commitfe9c95c to get more accurate results

@@            Coverage Diff            @@##            master     #1436   +/-   ##=========================================  Coverage   100.00%   100.00%           =========================================  Files          540       541    +1       Lines        13969     13989   +20     =========================================+ Hits         13969     13989   +20

☔ View full report at Codecov.
📢 Do you have feedback about the report comment?Let us know in this issue.

Have you searched through the issue tracker before submitting this? I remembered there is a reason that this is not implemented.

It was discussed at#101

Use can use a return type annotation asresponse_model, but in a case when it leads to some type errors it will be replaced withresponse_model keyword argument at endpoint decorator.

@phy25 What do you think about such option?

This was also discussed in#875, I ended up implementing the same in my codebase basically by creating a subclass of the APIRouter that I use to create all my routers.

@juhovh-aiven Thanks for the comment. I will do the same as you did.

I will close this PR. But I think that won't be the last PR regarding this feature😔

📝 Docs preview for commit1d6161c at:https://63567e2f28003420c0eae5ff--fastapi.netlify.app

@tiangolo Should I also update docs?

📝 Docs preview for commit8c4cf25 at:https://6356805d246dd92bb09291ac--fastapi.netlify.app

📝 Docs preview for commit685f402 at:https://6356824de6485c2a69a44560--fastapi.netlify.app

I just ran into this myself, can't wait for this to get merged in! Great job@uriyyo 😄

📝 Docs preview for commit01640c4 at:https://6366a6668c085d1c80d8798d--fastapi.netlify.app

@tiangolo I would love to use this feature in my project. Is there any chance you can include it in the next release?

📝 Docs preview for commit3b3d039 at:https://639cc85ab5df5c0d9667060d--fastapi.netlify.app

Thanks for the contribution@uriyyo! 🚀 🍰

And thanks for the discussion, everyone. ☕ 🍪

I added a couple of dozen tests to cover all the corner cases, interactions between return types andresponse_model, different types of declarations, data filtering, etc.

And I updated the docs to include all the information about this, how to use it, how and when to useresponse_model instead of the return type annotation, etc. 🤓

This will be available in FastAPI0.89.0 released (most probably) in the next few hours. 🚀

I have created simple route:

classResp(BaseModel):a:Optional[str]=Field(...,nullable=True)def__init__(self,*args,**kwargs):super().__init__(*args,**kwargs)print("init")@app.get("/")asyncdefroot()->Resp:res=Resp(a=None)print("Res created",res)returnres

And this log is not what I really expect to see:

INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)initRes created a=Noneinit

Probably it's ok forresponse_model case, but if I return model directly I do not expect it to be recreated by some reason internally.

Moreover, by that reason code is not working at all if I declare model this way

classResp(BaseModel):a:Optional[str]=Field(...,nullable=True)classConfig:fields= {'a': {'exclude':True}}

This seems to break in many cases. A lot of issues being reported on this.

Pardon my ignorance but what's thebenefit of this?

Before:

@app.get("/",response_class=PlainTextResponse)asyncdefroot():return"bla bla"

Swagger can infer that the response is going to betext/plain. I only have to specify what type of response it isonce.

After

@app.get("/")asyncdefroot()->PlainTextResponse:returnPlainTextResponse("bla bla")

Now Swagger defaults to thinking it'sapplication/json and I have to typePlainTextResponsetwice.

Yes, I'm a still a FastAPI newbie but I use it in a production project and was intrigued to see if this is something I should change to.

@Tishka17 the model is cloned to ensure that data is filtered, otherwise, if you return an instance of a subclass of that model (e.g. a subclass that includes apassword field), if the class is not cloned and the data is created again, it would pass Pydantic validation by default, just for being a subclass. That's why it has to be recreated. It will probably change and improve in Pydantic v2. You can read more about why is that here:https://fastapi.tiangolo.com/tutorial/response-model/#return-type-and-data-filtering

But if you have more follow up questions/ideas, please create a new GitHub Discussion question.

@iudeen could you point me to those issues reported related to this? Maybe in Discord? (because I'll lose it in the GitHub notifications). I wanna check if there's something specific flawed about this approach or just several corner cases.

As FastAPI is used by thousands and thousands of developers, any change will probably break some corner cases. But if the change is an improvement for everyone then it should be okay (that's also why I release so granularly, so many releases, so that people can pin and very gradually upgrade if there are changes that become problematic for them).

But if there's something wrong with the approach or the implementation, or if there's one of those "corner cases" that is very, very common (not so "corner"), then it could deserve its own fix/workaround.

@peterbe This is related toresponse_model, not toresponse_class. And in your use case, keeping the code you had would probably be better (that's what I would do). If you have more questions, please create a new GitHub Discussion.

@tiangolo the issues were resolved in 0.89.1