chridou
Relax StatusCode requirement on ApiError
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.
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.