Exception HTTP statuses

[bogdan]

Many http apis responds to invalid requests with correct http status like 404 or 500, but returns HTML body instead of specified in format.

So, going regular response parser in this case is bad idea.
In order to solve this problem I propose something like this:

raise ServiceNotAvailable.new(response) unless response.is_a?(Net::HTTPSuccess) 

Or raise an exception in case http response status is within a specified list.

[awendt]

+1 for the specified list of status codes that should raise an exception

[nzifnab]

+1 httparty doesn't seem to respect 404 or 500 error codes from the endpoint... hard to display a 404 page if i don't know the cause of the 'key not found' error.

Mmm, turns out I just wasn't fully aware of what httparty was doing. I can just get a handle of the response code by doing get('url', options).response.code, and render a 404 or sane error page when necessary based on that.

Leaving this comment here for future people that might want to know :)

[jnunemaker]

Personally, I think if someone is requesting json, they should always get json back. The status code has nothing to do with the body, if that makes sense. For gauges, we do this. 404's return json.

Right now we pass body and format to parsers. Seems like a better option would be to pass the whole response in place of the body. Then, if someone wanted to raise for 500, they could.

Any one have any thoughts either way on that?

[jnunemaker]

Scratch that. Passing the whole response means that parsers know too much. What would be better is making the parsed body lazy allowing someone to check response code before parsing happens.

[bogdan]

Looks good for me. Thanks.