this post was submitted on 12 Dec 2024
133 points (99.3% liked)
Programming
17651 readers
443 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The spec mandating its as a single string isn't that crazy. It's good to have a consistent response format so a basic deserializer can deserialize any error response object and get something out.
If you have different providers. One that returns
error: { code: string }and another does something else, you end up with the same problem this post talks about-- Inconsistency.As far as I can tell, the spec doesn't limit you to just the one field and you can add other optional fields to the top level to the response that the caller can optionally decide to handle. But if you know there's going to be a field called error that is a string. You always get at least something out of that to present.
Yeah, consistency is good, which is why it's good to follow the spec. I'm saying that the decision to make errors be flat strings in the spec was a bad one. A better design would be what you have, where
codeis nested one level belowerror, plus permitting extra implementation-defined fields in that object.