This is useful because you may want to specify the response info using the actual content header, e.g. application/problem+json. If you pass the Problem schema to a route's responses as a model, it seems to just use its return type as application/json. Still technically correct, but it could be nice to know the full thing.
Specifying the response would at this point still be left to the user
in the future we could maybe include a util to include some of this boilerplate as well, but that seems out of scope for this issue.
there should be a flag for this in the register method which could be either a string, or bool, defaulting to False.
If True, it will augment the OpenAPI scheme with the Problem schema under the "Problem" name. If a string, it will register it under that string as the name.
This is useful because you may want to specify the response info using the actual content header, e.g.
application/problem+json
. If you pass theProblem
schema to a route's responses as a model, it seems to just use its return type asapplication/json
. Still technically correct, but it could be nice to know the full thing.Specifying the response would at this point still be left to the user
in the future we could maybe include a util to include some of this boilerplate as well, but that seems out of scope for this issue.
there should be a flag for this in the
register
method which could be either a string, or bool, defaulting to False.If True, it will augment the OpenAPI scheme with the Problem schema under the "Problem" name. If a string, it will register it under that string as the name.
If false, it will not register.