Errors are one of the easiest things to overlook when creating an API. Your users will have problems from time to time, and an error is the first t...
For further actions, you may consider blocking this person and/or reporting abuse
What about?
That looks perfectly reasonable. I was mostly avoiding Go's actual "net/http" package. Not for any particular reason, it's a nice API, just wanted a slightly different approach. :)
I think retries and traffic management flow should be left on the service mesh level.
There is a good read here
istio.io/docs/concepts/traffic-man...
I would also love to see something like that in Go
thepollyproject.org/
Definitely good arguments to be made in favour of that, but somewhat outside of the scope of this post. 😀
Rust seems to be pretty similar to go. Most libraries define there 'own' error messages. I have a small library where I also added whether it was retriable (and if the error was cashed). The rust way is to return a result, witch either contains a value or an error. It's up to to user to handle possible error nicely, or not, in witch case the program will crash when there is an error.
In Clojure it's pretty common to just return nil when something went wrong. This is part of the language design, do unless Java where there is a high probability of a Null pointer exception, the result will probably just be that nothing happens. But if you want to, you can throw errors just like in Java. When you do get an error message in Clojure it's usually pretty vague, but work is done to improve on that.