Maybe the twitter_http_status_codes were a good idea. :P

I still think it's weird to have them, but I'm not against giving the
user more information. I put back in the twitter_http_status_codes
variable, but I changed where the logic was being handled, instead of
it happening the in _request, it will be asserted in Twython error if
an error_code is passed AND the error_code is in
twitter_http_status_codes
This commit is contained in:
Michael Helmick 2012-04-09 10:59:13 -04:00
parent eb22296e33
commit 813626a9ad
2 changed files with 21 additions and 3 deletions

View file

@ -328,3 +328,18 @@ api_table = {
'method': 'POST',
},
}
# from https://dev.twitter.com/docs/error-codes-responses
twitter_http_status_codes = {
200: ('OK', 'Success!'),
304: ('Not Modified', 'There was no new data to return.'),
400: ('Bad Request', 'The request was invalid. An accompanying error message will explain why. This is the status code will be returned during rate limiting.'),
401: ('Unauthorized', 'Authentication credentials were missing or incorrect.'),
403: ('Forbidden', 'The request is understood, but it has been refused. An accompanying error message will explain why. This code is used when requests are being denied due to update limits.'),
404: ('Not Found', 'The URI requested is invalid or the resource requested, such as a user, does not exists.'),
406: ('Not Acceptable', 'Returned by the Search API when an invalid format is specified in the request.'),
420: ('Enhance Your Calm', 'Returned by the Search and Trends API when you are being rate limited.'),
500: ('Internal Server Error', 'Something is broken. Please post to the group so the Twitter team can investigate.'),
502: ('Bad Gateway', 'Twitter is down or being upgraded.'),
503: ('Service Unavailable', 'The Twitter servers are up, but overloaded with requests. Try again later.'),
}