Closed damooo closed 1 year ago
Hi!
The HttpApiProblem
is more or less simply a serialization container. It is not meant to carry any other information other than what is to be sent over the wire.
The ApiError
instead is meant for being returned and carried around in the application and by the time creating an ApiError
the status code should already be known.
If ApiError
is used, one should never get in touch with HttpApiProblem
.
Maybe I misunderstand something here.
We are using ApiError
as general dynamic error type, instead of just for http api endpoints. In that case we only define error types, and match over them for actions over an error, and no status codes. It is working just great with all extensions, etc. Only status code requirement causes inconvenience, as no such thing is defined for such application level error types.
Uh. This is not the intended use case. But nevertheless. Would it help to have a something like a new_500
method so that you do not have to import StatusCode
to create an ApiError
?
I would really prefer to keep it mandatory and not having users to rely on another implicit "a None
will be a 500` mechanics where avoidable.
Currently
ApiError
mandates explicit status code. In many cases middleware may just know problem-type and, let higher layers act based on problem type. Thus status-code is not known always.Though
HttpApiProblem
allows that, it doesn't support extensions, source, etc.One can always fallback to 500 at the time of conversion, if not explicitly set.