Stop returning custom error responses from your API. Do this instead.

In today's video we'll cover the problem details specification (RFC 9457, previously RFC 7807).

All HTTP APIs should use the problem details specification, as it defines a consistent, machine readable schema for error responses.

So in this video we'll cover what the problem details specifications is, how to use it, and how easy it is to integrate it in your ASP.NET applications.

Connect with me on 'em socials: 

Check out all my courses on DomeTrain: 

Support the channel and get the source code:

Thanks for watching, don't forget to like & comment & subscribe! ❤️ 💻

[rrraewr]

my api is going to reply with "oopsie woopsie you made a mistakey" and you'll be happy

[olivier]

I am learning a new thing with your video. Never heard of that feature.

[alexdarby]

In the enterprise corporate world, it is not as simple as using existing industry standards as business have their own set of requirements, for example, do not give detailed error messages in responses

[XCanG]

I didn't test it, but I don't like this suggestion. There are a lot of tools build around REST and some of them rely on MIME type, going to introduce more types would make those tools not recognize it as json, I believe even if I will look at response in devtools it wont parse it as JSON, but as a string and you couldn't interact with it the way you interact with JSON. You already have status codes. I would agree if you suggest instead of returning 200 Ok all the time, return like 400, 403, 409, 422, etc. But that's all that you need. There is 0 benefit for returning "409 application/problem+json" vs "409 application/json", because it's not 2xx/3xx, so there would be always the problem.

[RushOrbit]

Thanks for sharing this. Error messages are such an important part of a well designed API. I think the additional params being added with the balance and stuff are helpful. I would place them inside of a context object to separate domain data from the API error messaging. Lastly, error codes should not be done away with. Using error codes allows your frontend app to be localized so that the it can display the error message it wants to the user in that user’s language. Sure, you can return your error messages already localized, but making the API’s error handler aware of the user’s locale doesn’t sit right with me. Additionally, the interfaces may vary so the wording of the user message will differ (Tap to retry applies to mobile, but click to retry applies to a desktop app). I know a lot of this is preferential though. Many thanks! 👍🏼

[siya.abc]

68 and 421 were chosen at random I'm sure 😅

[Eirenarch]

I am using problem details, not very happy about it. It is better than nothing but it is absurd that every attribute is optional according to the spec. In addition people tend to use the type as the equivalent of the status code just like you did in the video. This doesn't seem to be the original intent and even if it was it is useless. Unless you have the most generic bad request (i.e. the submitted data was not in the specified format) you want to have your own type on your own URL (you can skip actually having anything there if the consumer is your team). In your case where the bad request results from specific if branch in your business logic you need a separate URL. This lets the client handle the problem differently than regular bad request. You are putting these extensions, this number but how will the client know to look for it if your type is just like the type of any other bad request?

P.S. just checked the newer spec. Well, at least now the type attribute is mandatory.

[CarlosEstebanLopezJaramillo]

I wonder how this plays with security, most people would say not to give too much info on errors, it could give away vulnerabilities and such.

[evancombs]

I like it in theory, but I'm practice I've found very little use for it.

[martinaa]

Nice video!! Whats the program you use to made the draws while you explain, like the boxes and arrows. Thanks!!

[Tidbit]

Hi, nice video :) What software are you using to draw on the screen?

[AnotherUTubeAccount]

This is interesting, and might be a bit better than what i do now in my frontend api. One thing that i recommend is to use the instance property in the spec, and fill it in with a NanoID that you log on the server. That way you can pin a specific instance code to find related log messages. Thats similar to your request id, but i use a XXXX-XXXX format. And its much easier for people to read off than a UUID. And you can exclude vowels to make it easier.

[damongerman]

Recently, we introduced an aggregation service. The problem details contain the most significant error, and we add the other errors in the extensions as nested problem details.

[billybob]

In my API I had gone out of my way to wrap every single possible error I could into a single custom but consistent 'ErrorResult' object as application/json.
Even went as far as registering custom filters and services just to ensure every single API source of 4xx/5xx errors would get caught too.
A big motivation for me was that I had just dealt with a SOAP API that did error handling in about 20 different ways - it was infuriating.
I guess I independently came to a very similar but more primitive solution than this standard.

I'll have to keep this Problem stuff in mind for the future.
That said, I'm not really too bothered with how APIs report their errors.
I just ask that you *PLEASE* standardise on 1 method; not 2, not 5, not 1 per possible error condition, and most certainly do not extend that to be unique per API Call like that SOAP API did.

[handomize]

Maybe this could be a benefit if its showing the error message to an ui, however i have serious doubts on the scalability of it. Because its a way more involved process to add and maintain across all of the project. I would wrap it in a data property so we could have a better type checking

[joehead]

Interesting, I'm curious about 2 scenarios. What would you return if the request is technically valid but it fails some business logic calculated on the backend? Also what would you return as a response if there are multiple objects sent in a request but there a mix of failures and successes?

[MrAlkazam]

Nice video, thank you for sharing these tips and tricks.

[Suriprofz]

What about localization, so multiple languages.

[matthiaskohler]

Don't get the benefit. The extensions are custom as well. It seems the initial problem of dealing with api error responses individually persists. Whats the benefit over http status codes and json response.

[PatrickSteil]

The spec needs a mandatory “resolution” field. Who cares what the error is. Tell the user how to fix it!