Hi,
I tried calling the following url: https://api.guildwars2.com/v1/wvw/match_details.json?match_id=1 I received an error 500.
Since the match with id 1 doesn’t exist either, you should return an error 404, telling me that I made a mistake, not that you made an error while searching for the erroneous input I gave.
Having errors map to more specific HTTP status code is a good idea, but the reality is that we have many more complex error codes than we can map to HTTP statuses, and the errors may originate from backend servers that have no knowledge of HTTP.
Generally the way error handling should work is this:
result = get(/v1/events.json?event=123);
if (result != 200) {
error = parseJson(resultBody);
if (error)
showErrorToUser(error);
return;
}
Our error handling policy is to try to show the original error information to the user instead of hiding it. If a user reports a bug and includes the error code, there’s a good chance that we will be able to figure out the problem.
In other words, if you have a web server that talks to our API and returns results to a web browser, and you receive an error from us, try to send that error to the browser instead of swallowing it and generating your own error.
OK, on a separate topic this thread made me realize that error 500 was a bad choice. I propose changing the APIs to return error 400 instead.
Hi There,
I’d like to address this 500 error problem a bit:
My proposal is to only return 500 on a relatively small set of known internal errors. Otherwise, I assume it is user error and return 400. I thought about trying to map to more granular HTTP errors, but as Cliff posted above it is a difficult and un-maintainable job.
With my proposed fix, it is still possible that I missed a few “internal” errors which will come back as 400. But as before, the error details will be provided in both 400 and 500 cases. I can always add more errors to the “internal” set as needed. In general, there are many more “user-error” than “internal-error” type codes in our system.
When authenticated APIs come out, I will likely introduce the 401 error code as well.
Any thoughts on this?
Thanks for the feedback guys.
Dr. Ishmael, your argument is interesting: just return 200, 404, and 5XX and let the caller parse the results for details.
However, I do think keeping 200 for truly ‘success’ cases makes sense because internally we have one-and-only-one ‘success’ code used across the gw2. So this will always translate correctly and it doesn’t prevent anyone who wants to treat 4XX and 200 the same, relying instead on parsing the JSON for errors.