500 server error's are not invalid

[cheneveld]

#24 demonstrates 500 errors that are not "invalid".

Was this intentional? Should we make invalid responses include 500 status codes?

Should it be handled differently?

[erkie]

The idea was that isInvalid only relates to client-side errors, but seeing as a lot of 4xx errors relate to things the user cannot impact, I understand the problem. Looking at the list of status codes and how the code is structured, https://en.wikipedia.org/wiki/List_of_HTTP_status_codes, it would probably be approprioate to have an isError on the ApiResponse class.

Maybe even rename them to isHTTPInvalid, isHTTPSuccessful and isHTTPError, then we can create a more user friendly isError and isSuccessful that uses those three.

The reason you noticed this though, is that becaue of #27? Because accessing the rawResponse is probably not what we want the users to do anyway. It should still be cleaned up to be made more inuitive though.

[cheneveld]

We can narrow down the response states to these 4:

1. success (2xx) isHTTPSucessful = true
2. Validation errors (422) hasValidationError = true
3. Server error (500) hasServerError = true
4. Invalid requests (400s other than 422) isInvalid = true

I think the user should know about these state in every completion block. Also, 1/2 are meaningful to the object and 3/4 are not.

I'll still ponder this.

[cheneveld]

#31 addresses this