Currently a Twitter::RESTError is raised when any type of error occurs on the REST API side. While it contains the status code inside the RuntimeError object subclass, it would be easier to discriminate with different rescue blocks based on the type of RESTError is raised by the Twitter.com API.

Types of errors to be modelled:

• 304 - Not modified, i.e. no new results since last query.
• 400 - Bad Request, i.e. reached rate limit.
• 401 - Unauthorized, i.e. missing or incorrect credentials
• 403 - Forbidden, i.e. reached update limits
• 404 - Resource Not Found, i.e. the user, tweet, etc that was being accessed does not exist.
• 406 - Not Acceptable, i.e. format specified in request is not understood.
• 420 - Search Rate Limit Reached, i.e. on the search API 420s are returned to notify client that they are being rate limited and they should abide by Retry-After header.
• 500 - Internal Server Error, i.e. Twitter.com API is borked - post error messages to the relevant Google Group for the Twitter.com API.
• 502 - Bad Gateway, i.e. the Twitter.com servers are being upgraded.
• 503 - Service Unavailable, i.e. Twitter.com servers can't handle all requests currently.