4 ms·
Dig the article. A couple of things. 1) I can see what you mean for handling auth keys in query string as opposed to "key:" using basic auth. I started using th
by jksmith 13y ago
Dig the article. A couple of things. 1) I can see what you mean for handling auth keys in query string as opposed to "key:" using basic auth. I started using the latter pattern after I went through easypost's api docs. Even though "key:" is a little unbalanced I guess I still dig the basic auth way. YMMV. 2) On error messages, I wrote some code to provide extended info only if the req host is in a white list (set up your white list in an ini file or whatever). I was originally just throwing back a 500 plus whatever the error returned, but the db error info returned by some of the golang drivers is detailed enough that I didn't want to share all of it. Just curious if you had noodled on this issue if it is one for you.
- thecodemonkey 13y agoThanks! Hopefully 500 errors would never occur of course, but in that case I'd just return: { error: "Internal server error, please try again later" } There's not really a reason to give away anything else, it's usually because something is broken (database connection and whatnot) and the developers are probably already aware of it with tools such as Bugsnag[1] and alike. In general for error messages, exceptions should be handled gracefully and output a simple message that is understandable for the user. It might also be ideal to include an error code with the JSON response if you have a lot of different error messages that happens under the same HTTP status code (e.g. 400 Client Error). [1] https://bugsnag.com https://bugsnag.com
- jksmith 13y agoCool. Thanks for that. Yeah that's a good thing about golang. No exceptions (levity alert)! So it's always a message you get back unless somebody hit the panic button.