API errors wrapped in APIException cannot be reliably acted upon

[matt-snider]

APIException as it stands has very little use.

A specific problem I see is that it does not maintain any details about the request or response in a machine readable way. It seems sensible that a class called APIException would return some details about the response (e.g. API error response message, status code), yet these are only present in the message, which would need to be parsed (e.g. "Invalid status code %d, errors: %s"). Parsing exception messages this way is very brittle and is not an acceptable approach in production code.

An example use case would be deleting an address from a route. If the server responds with 502, the caller should bail (or retry) because Route4Me may be temporarily down. If the server responds with 404, then we would handle it completely different (e.g. the address has already been removed, an invalid ID was provided, etc).