API Error Messages for a GOOD Developer Experience
Вставка
- Опубліковано 9 лип 2024
- Debugging and troubleshooting are a big part of a developer's day-to-day. Because of this, when designing your APIs, provide good API error messages as well as guide developers down a path of success and makes it easier for them to understand issues when they need to troubleshoot.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
0:00 Intro
0:36 What and How to Fix
2:17 Be Explicit
3:54 Path of Success
5:42 Problem Details
6:38 Read the Error/Stack - Наука та технологія
And boom goes the dynamite 💥... if you go that reference!
But I guess it makes more sense to design the behaviors in the back-end if you need to serve multiple front-ends implementing the exact same behaviors.
I dislike all these tutorials (often created by amateurs) that simply tell people, 'Don't do this, don't do that,' without discussing the advantages and disadvantages of each approach. In reality, whether it involves using exception or returning error approach, both methods can be appropriate. Each has its benefits and drawbacks, and the best choice depends on the specific context.
Context is King👑
You can use try catch no problem on that . For me , just return array or false status only as we use ajax respond. The smaller is much better . Do remind , always log your error upon catch error . If you don't have error handling , it kinda hard to debug for long term . We do tutorial but not in this nick name. The best trend not return try catch error like old days but still we need a backup if something happen.
I like to do this too. I implemented a pretty robust error mechanism for REST APIs, but then the security team and product management colluded and told me I have to make more generic errors because I'm giving away attack vectors and its all too complex for the user. 🤷
Yeah, the errors returned from the api and the errors thrown are two different things. He’s talking about the code level
I want to reduce the number of support requests for whoever the intended message is for.
Could still just be a bad security team. I've had so called security people tell me to hide things in the name of security before because they don't understand that obscurity is not security e.g. you should make the API require authorization, not try to hide something like an order id.
I ended up base 64 encoding it to shut them up and they were dumb enough to think that helped, but sometimes it's just politics.
You can record the real errors in your log and return more generic msg from your rest API. Use a middleware for this so you can change behavior for prod and integration environments.
generic mean like owasp but you still need return a log to understand for admin if anything happen wrong.
Option is not really a good replacement for exceptions because you might have different types of errors you want to "return" to the caller.
I think the Result monad is better here since it usually carries an error List which can then be translated to api errors.
Agree, assuming you have more than just one outcome.
for basic lookup on an entity i think Option is great, but agreed if something else fails then Result is better. Though i think result quickly turns into a hammer, and everything must be a result. At that point you loose your clarity of return types.
If there is a chain of function call A -> B -> C -> D, and each function returns a Result type, then every function needs to do an "if-else" check . This according to me is a bit too much.
I prefer exceptions, so that the code reads very declarative . The exceptions needs to be caught at the edge of the systems (like the API controllers).
Exceptions are for exceptional cases. Not finding some stuff by an ID is not exceptional.
One of the things that's bugging me with throwing exceptions for things like not found or validation errors is that you'll see those in your logs as errors when in reality they're not really errors in my mind. You'll then see an error level message in your logs whenever a user submits a request with a missing field and at the same time the other error messages can be actual errors like the connection to a database timed out. But trying to convince everyone else at work to abandon using exceptions to control flow is damn near impossible.
Yeah, but it's important. There's this great book called "Effective Java". It has a chapter about exceptions which, among other things, speaks about this problem. I don't know if you use Java, but I guess most of the principle about exceptions apply in other languages as well.
Its pity option is not builtin, instead, ? is recommended.
Fellow hockey player here. Love that you play hockey. Flip your video in editing so it's not reversed lettering!
Thanks for all your great content. Very helpful!
First person to notice! Just how my setup is at the moment. I plan on switching it around so its not reserved soon enough.
How do you deal with the Option type across multiple DLLs? Do you define them in every project? Do use a "shared" folder with Util methods/types in it? How about when you have an internal nugget package that has it?
Kinda of a bummer that C# still has not added Union types yet.
Any of the above. Agree, I wish there was not only something built in but also as a c# feature that was easer to use. It can often be a bit clunky.
throw new Ex("programme's note to self: Oops")
Thumbs up for use of Option
I have to use an API that may omit a whole relation block when it doesn't feel like giving it and have to retry max 10 times to make sure it actually doesn't exist.
That's worse than bad error messages 😅
What Option library do you use?
It's easy enough to create your own.
Its not that simple as it adds maintenance. Now you have to make sure that your 'advice' is true. For example, they could remove that coupling but now you have to remember to update the verbiage.
In practice error messages are opaque strings you throw into some kind of search engine/ai
In majority of practice, they are for sure. It absolutely can be a maintenance burden on you. But like many things, it's what you value. Do you want the burden of maintaining correct and accurate errors, or do you want to put the burden on your consumers to decipher the error to find a solution? As always, depends on your context. It reminds me of the idea of versioning your HTTP API and Roy Fielding saying "a v1 is a middle finger to your API customers".
We prefer handling our own application exceptions in a global exception handler. Much esier and it doesn't affect performance in our regular successful calls.
Just make sure you raise exceptions only for exceptional, i.e. unexpected (unexpectable?) problems. Not finding an order by some ID is not exceptional, since the "findOrderByID" method has no control over the ID passed in. The caller must handle this case eg. by giving the user some sensible feedback or trying/suggesting an alternative. A simple "catch all" block in some central place will not do that. However, it is a good strategy for catching everything that was not caught elsewhere.
@@bernhardkrickl5197 we define our custom exceptions in the Application layer