Add response content to ApiException class

[Anton0]

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

adds a response field to the staxapp.exceptions.ApiException class, this allows users to use the response even in error scenarios, an example might be when creating an account type that already exists the API returns HTTP/400 which the SDK raises an exception for, however the api returns the details about the existing account-type but doesn't pass them back to the calling code.

example

    except ApiException as e:
        if e.status_code == 400:
            print(e.response['Detail']['AccountType']['Id'])

this means the user needs to make another get call just to get the existing ID

• What is the current behavior? (You can also link to an open issue here)

the response data (json or otherwise) is logged but not stored meaning users need to make a second call or attempt to string parse the logs 🙅

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

no - this only adds a new attribute to an existing class

[codecov]

Codecov Report

Merging #83 (157ff91) into master (d9c857f) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #83   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            8         8           
  Lines          434       436    +2     
=========================================
+ Hits           434       436    +2     

Impacted Files	Coverage Δ
staxapp/exceptions.py	100.00% <100.00%> (ø)

[ZXYmania]

Looking at the Api Spec we only return Cause and Error for an Error response json. Allowing Customers to see the response may confuse them as to why some have content and others may not. With this in mind are the changes worthwhile? I now see you've given a valid use case but I do worry about exposing the inconsistencies of the api

[samdammers]

I would like further discussions on error responses, but providing access to the content is a good start.

[Anton0]

Yup - valid concerns, but in lieu of more consistent API responses provided access to the existing responses I suspect is still better than requiring capturing stdout