Improve 204 support

[kibertoad]

Changes

ToDo:

1. Tests for GET with 204 response cases
2. Tests for non-JSON get responses
3. Tests for different variants of isEmptyResponseExpected/isNonJSONResponseExpected params
4. Look into "unsafe any" linting error
5. Extra documentation

Checklist

• Apply one of following labels; major, minor, patch or skip-release
• I've updated the documentation, or no changes were necessary
• I've updated the tests, or no changes were necessary

[kibertoad]

@ondrejsevcik @szymonchudy How would FE prefer to be communicated about special cases? Currently it would just return entire Response object in case something isn't considered a direct error, but is an unusual situation (e. g. non-JSON or expected as possible empty content came back). Is that good enough? We can return an Either with a defined set of possible result codes instead.

[ondrejsevcik]

If the isEmptyResponseExpected is true, then this is not really an error case from the point of the caller. I would expect that it would return successful promise resolution with undefined/void value.

The code could check the response status, and if it is 204, then the parsing should be skipped IMO.

[kibertoad]

If the isEmptyResponseExpected is true, then this is not really an error case from the point of the caller. I would expect that it would return successful promise resolution with undefined/void value.

Fair point. We can use a more bespoke structure then Either then, with three possible fields: Left (error), Middle (non-error deviation from main path) Right (expected main path response). If Right is set, we proceed with the main path, if left is set, we handle an error, if Middle is set, we check the code returned and handle it in a custom way.

The code could check the response status, and if it is 204, then the parsing should be skipped IMO.

Aren't we already doing that in this PR?

[ondrejsevcik]

@kibertoad maybe I'm looking at a wrong line, but I think we're not checking the status before parsing.

[kibertoad]

@ondrejsevcik check the tryToResolveJsonBody itself

@CarlosGamero We probably should have the check in the consistent place for both GET and non-GET scenarios, I think currently I did it explicitly for non-GET and implicitly (within tryToResolveJsonBody) for GET.

[CarlosGamero]

@kibertoad I will change it to use the same approach on both places 🙇

[CarlosGamero]

Already changed