[BUG] v2 pagination error message
Dr Ishmael.9685:
I found a bug with the errors returned for bad pagination requests – they don’t match the “standard” format returned for other errors.
Pagination errors:
{"text":"page out of range. Use page values 0 - 191."}
{"text":"page_size out of range. Use page_size values 1 - 200."}Standard errors:
{"error":10,"product":0,"module":2,"line":427,"text":"invalid item_id"}
{"error":90,"product":71,"module":2,"line":378,"text":"CnConn: language not supported"}My v1 code was relying on the presence of the “error” attribute to detect request errors. Would it be possible to standardize the pagination errors – at least give them an “error” attribute?
Pat Cavit.9234:
Why aren’t you using the HTTP response code to check for errors?
Those errors are coming from different levels/servers, so it’s not super surprising they’re different. We can take a look at standardizing but you should always use the HTTP status code first and foremost.
StevenL.3761:
The error code is useful to determine which parameter was invalid.
10 = invalid identifier
90 = invalid language
You could then use that information to do things like display localized error information, which is useful because error responses are always in English regardless of the given ‘lang’ parameter.
Dr Ishmael.9685:
https://forum-en.guildwars2.com/forum/community/api/Return-proper-error-codes/first#post2961806
API v1 was originally using non-informative HTTP codes, so I wrote my module to look at the returned JSON instead. I never bothered updating it after Stefan’s changes because my method “just worked.” I guess I’ll have to update now.
Pat Cavit.9234:
https://forum-en.guildwars2.com/forum/community/api/Return-proper-error-codes/first#post2961806
API v1 was originally using non-informative HTTP codes, so I wrote my module to look at the returned JSON instead. I never bothered updating it after Stefan’s changes because my method “just worked.” I guess I’ll have to update now.
I can’t possible disagree more with your proposal in that thread, sorry. Errors should always return the most-appropriate HTTP error status code in the response. Extra information kittentainly come back in the response body (and we need to do better standardizing those) but the status code should always be the very first thing any consumer checks once a response is received.