Overriding Validation Error default schema used in API document

[otsuka]

In my app, I customize RequestValidationError response using exception_handler as below:

@app.exception_handler(RequestValidationError)
async def request_validation_exception_handler(_request: Request, exc: RequestValidationError) -> JSONResponse:
    data = {
        "error": {
            "code": Error.REQUEST_VALIDATION_ERROR.value,
            "message": "Intput data is invalid.",
            "detail": exc.errors(),
        }
    }
    return JSONResponse(content=data, status_code=HTTP_422_UNPROCESSABLE_ENTITY)

The generated API document includes automatically the default Validation Error schema, HTTPValidationError, in all POST or PUT path operations.
So I need to add my responses definition one by one.

responses = {
    422: {'model': APIErrorResponse, 'description': 'Validation Error'}
}


@router.post("/", responses={**responses})
async def create_user(user_in: UserCreate):
    """Create new user.
    """

@router.put("/", responses={**responses})
async def update_user(user_in: UserUpdate):
    """Update user.
    """

It would be useful if we are able to override the Validation Error default schema used in API document.

[dmontagu]

It may not be the "cleanest" answer, but it is actually pretty easy to manually modify the openapi schema as desired. If you just call app.openapi() and modify the returned dict, it will remain as modified (so you can do this during server setup, for example).

You can see a complicated use of this in the expandable box at the end of this comment. Updating the ValidationError schema with a custom dict should be substantially simpler than that.

That said, I wouldn't mind a cleaner solution.

[chbndrhnns]

+1 for a cleaner solution :)

[otsuka]

@tiangolo
Thank you for your reply.

The code you suggested looks like one way to change the default schema, but I would like to have cleaner solution.

[tiangolo]

You can set the responses parameter at the router level: https://fastapi.tiangolo.com/tutorial/bigger-applications/

[otsuka]

@tiangolo
Thanks a lot!

Using the responses parameter in include_router() method, the API documentation now reflects the custom validation error schema.

[rooterkyberian]

Using responses= at router level adds 422 response definition to all endpoints, even one not having all parameters, so this is not ideal solution.

[kinuax]

@rooterkyberian, the responses parameter can also be applied to the path operation definition. More info at https://fastapi.tiangolo.com/advanced/additional-responses/#additional-response-with-model and https://fastapi.tiangolo.com/tutorial/bigger-applications/?h=responses%3D#another-module-with-apirouter.

[rooterkyberian]

I know that, but for whole service, (in fact multiple services) we have a standard error response format, so I would love to register it once and have it automatic on everything that can possibly throw ValidationError, just like I register ValidationError exception handler once for everything.

Right now there just doesn't seem to be a way to do this cleanly.

[ryzhovalex]

I've faced a similar problem with attaching custom ValidationError response not globally, but only locally where it really can occur.

I haven't found clean solutions too, but for those who interested in any approach, it would be good to create a custom proxy methods to FastAPI's ones and do some sort of parameter inspection there. If certain decorated route handler accepts any arguments which should be validated, our proxy method will notice it and will add required responses to it.

E.g.:

def custom_get(*args, **kwargs):
    def inner(fn):
        signature = inspect.signature(fn)  # or typing.get_type_hints(fn)
        
        # Do some logic according to received function signature
        custom_responses = ...
        
        your_app.get(responses=custom_responses, *args, **kwargs)(fn)
        
    return inner