Response types normalization

[RobertoPrevato]

Hi @tiptop96, I thought to write a message here because yesterday evening I published an update to the framework, related to the thing you wrote about your middleware. I realized, thanks to you and thanks to ASP.NET Core WebApi project template, that my framework was indeed lacking (without good reason) request handlers normalization for return types.

I implemented a first basic support in 1.0.2, which also enables automatic generation of OpenAPI documentation for response types (only 200 and JSON / plain/text scenarios) (58331d5).

For example, in ASP.NET Core you can do:

[HttpGet]
public async Task<IEnumerable<Country>> GetCountries()
{
    ///
}

And Swashbuckle for example can generate automatically the response type documentation for the list of Country for this method. Now in BlackSheep it works in the same way. You can define for example a dataclass or a Pydantic model, and request handler + automatic generation of OpenAPI Documentation defaults to JSON in this scenario:

@dataclass
class Country:
    code: str
    name: str

@app.route.get("/api/countries")
async def get_countries() -> List[Country]:
    ...

The framework doesn't assume anymore that request handlers return an instance of Response, this improves the user experience for developers.
The only downside is that when the developer doesn't specify the return type with annotations, the framework needs to wrap the request handler inside an additional wrapper, which of course incurs in a performance fee (I didn't measure, it's most likely negligible, but still existing). Unlike the normalization happening for input parameters, the normalization for output parameters, when the developer doesn't annotate a request handler with a return type, requires some inspections at each web request because you don't know what kind of object the request handler will return, until the method is called. Details can be seen in normalization.py.

I am creating a discussion here, to keep a thread on this topic.