this post was submitted on 02 Sep 2024
221 points (98.3% liked)
Programming
17484 readers
118 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 !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Problem Details for HTTP APIs - I have to work and integrate with a lot of different APIs and different kinda implementations of error handling. Everyone seems to be inventing their own flavor of returning errors.
My life would be so much easier if everyone just used some 'global unified' way to returning errors, all in the same way
Please guys, stop using line-breaks mid-sentence. It's not the 90's anymore, viewers generally can wrap.
Maybe a bad markdown viewer?
~~viewer~~ generator?
No, in general the markdown format suggests using line breaks in the middle of paragraphs to make the code just as readable as the output. That’s why two line breaks is what creates a new paragraph. So it’s the viewer showing it incorrectly here.
The screenshot is of the website ietf.org , which doesn't seem to be markdown.
That would be nice. I have implemented this in the past but never once encountered an API that used it.
Saving...
I made my first API at work last year (still making) and always saw myself looking for input on making a consistent way to return errors, with no useful input from the senior programmers or the API users. This is my second biggest problem, the first being variable and function names of course.
If I were to do anything related to HTTP, I now have something to look at.
Best is when the API doesn't match a PDF and says "500: Internal Error"