[BUG] v2 pagination error message

#1 - Sept. 26, 2014, 3:44 p.m.

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

#2 - Sept. 26, 2014, 6:34 p.m.

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.

Pat Cavit

#5 - Sept. 29, 2014, 1:15 p.m.

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.

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.