Raise client error for unhandled 4xx responses

[jamesstonehill]

Resolves #308

[gaorlov]

This looks solid. Thank you so much for the contribution! Can you take a look and see if the test failures are due to your changes?

[jamesstonehill]

Doesn't look like it. Looks like some kind of test file load order thing.

[gaorlov]

@jamesstonehill those are the worst. Alright. Rerunning seems to have fixed it. I'll take a look later. Thanks!

[gaorlov]

Oh. One last thing: can you add a description to the Changelog.md?

[gaorlov]

@jamesstonehill 1.6.2 is live

[marybethlee]

This is causing 422 errors to raise an error again, which was something that was reverted in this commit: 819531a#diff-a5876160692c35f965ad9d0dc8d46f69

422 errors are usually used for resource validation errors, should that particular status be excluded from the ClientError?

[gaorlov]

That's not excellent. How would everyone feel about explicitly defining every 4xx error as its own error class?

[jamesstonehill]

Why was that reverted? Raising an error may not be the best way to handle a 422 but it's far better than failing silently.

[marybethlee]

I think most people would expect 422 to not raise an error, because the response is returning errors on the resource, and the gem is handling that appropriately -- the model.errors is filled with the data from the response

To not break compatibility for now, the easiest would be to not raise on 422 errors, and a more customized approach would be to allow users to configure how they want 4xx errors to behave

[jamesstonehill]

Yeah, that's a good point. Since these responses would populate the model errors raising probably isn't right here. Probably best to revert.

[marybethlee]

@jamesstonehill I think raising on the other 4xx errors is appropriate, it's just the 422 that should be ignored.

[jamesstonehill]

Are there any other 4xx statuses that might return validation errors?

[jamesstonehill]

https://github.com/JsonApiClient/json_api_client/pull/312/files

[marybethlee]

I'm not sure if there are other statuses that might return validation errors, and the json api spec isn't specific about the 4xx errors, but 422 seems generally accepted.

[gaorlov]

I think it's reasonable to allow them as they come up