BEYOND Status Codes! Better REST HTTP API Error Responses

💥 Join this channel to get access to source code & demos!

🔥 Don't have the JOIN button? Support me on Patreon!

0:00 Error Examples
1:46 Problem Details
5:01 ASP.NET Core Controllers
6:21 Middleware

#softwarearchitecture #httpapi #restapi

[TheRicherthanyouguy]

I literally wish I had seen this a few weeks ago. I just enhanced the error handling of API and this would have been a far more effective solution that mine.

[bobbycrosby]

A big problem with only relying on http status codes is it assumes things can only go wrong in 1 layer. That's why I always wrap application-level responses in some kind of json. Even the 200 ones. I've seen misconfigured servers returning 200 {} when processing never actually hit the domain logic. Servers will happily return 404 all day long if you're pointing at the wrong place.

Not being able to tell the difference between "user 123 does not exist" and "what the heck are you doing i don't know what /users/ means much less /users/123 is" in your code is a bad place to be in.

[codyspeck]

Informative. Thanks Derek! I hadn't heard of the Problem Details specification before.

[srik]

Hi, Awesome video...please also cover ValidationProblemDetails also

[HamzaFouads]

I used to follow the standards in the past but actually it is not quite worth it..
There is an overhead on each response just to be stick with the standards...

"status" field is already handled by the HTTP call so why add it twice?
"title" and "detail" actually represents the same meaning :) or if necessary you could also add both under a "detail" field
"instance" is just the uri you personally used why do you need the response to remind you of your request
also the "traceId" is rarely used so it could be ignored too.

[lchl]

Cool, this is new to me!! Knowledge gathered :)

[ricardo]

Nice one, didn't know about this specification/standard. Thanks

[alexandrewerner]

Very useful! I will start to use this approach in my personal projects. And bring it to discuss with my team.

[RasmusSchultz]

Why does it duplicate the HTTP status code into the message body? That seems like a really bad idea. What if they don't match? Which one should the client respect? This seems to invite problems and has no particular benefits.

[Illyasviel]

Does the "type" need to be a valid URI, like when opened via a browser, opens a valid page? If so, what should that page output? Thanks in advance

[dewanganskitchen]

Getting DOCTYPE html in api response how to resolve

[gilleswetzel]

Thanks for another great video! I have recently implemented something similar, I was not aware that there is a standard for this. Do you have a suggestion how to return multiple errors / problems in one response?

[ItsJustEza]

How do I handle ProblemDetails and its' possible extensions on the client side, in TypeScript? In my ProblemDetails model do I use [extensions: string]: ValidationError[] | string | number, etc? Or do I have a different ProblemDetails model for each response? E.g. ValidationProblemDetails extends ProblemDetails{ errors: ValidationError[] }. How should my client-side app handle whether the response was a success and process some "success" response type <T>, or whether there was a problem and it should process the response as a ProblemDetails instance? There is a lot of content around about how to do ProblemDetails on the server side, but not so much for how to handle on the client side.

[adambickford]

Seems like you're going to need those extensions to do anything particularly useful/elegant. At that point I'm not sure this provides a ton of value, I'll have to investigate the support around this. If I can pull it off w/a couple annotations or whatever, great!

We use HTTP 422 Unprocessable Entity so we know 4xx is probably a technical concern and the 422 is a business concern. We also know how to parse the error payload based on status code. The payload is a struct with the 'path' of the request dto field as the keys and array of errors related to the field so the client can localize and associate with the UI elements. Empty path value is used for errors not related to the DTO/request like an optimistic locking error.

[madskaddie]

my interpretation of the instance field is more like your traceid and not the url at which the problem was generated: an uri that, when dereferenced, returns information about the error instance itself. in simpler cases, I use the db to persist that info. In more distributed cases, I have an error server responsible for that. Handling this is done in a best effort (it must not hide the original problem if something goes wrong in this process).

i'm careful to avoid exposing implemention details information to third party clients (ex: stack traces)

[brucewayne]

Amazing, didn't know that, thank you !!
But is this for any kind of API or only public apis ?
what is the purpose of the status property if the http Status Code is always available ?

[rafaspimenta]

Great content!
By the way, when will we have a course from you on DDD / microservice / web API? :P

[rustamhajiyev]

Nice, I didn't know about that. Will give it a try. Thanks for sharing!

[cml]

I have a question, probably not 100% related to this, but.... Regardless you return or not useful information on response, should a "no credit", or "out of stock" return an http 400 with some additional information, or return an http 200, with an IsValid=false, and additional description? From my point of view, the request was not bad and was completed

[leuquim]

I like this extension and the use of middleware but i find myself having to raise exceptions to propoagate an error to the response, and i also can't use the "details" data in production to output messages in the UI beacause then i'm also exposing other sensitive data like stacktrace etc...