500 server error's are not invalid
https://github.com/erkie/ApiModel/pull/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?
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 https://github.com/erkie/ApiModel/issues/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.
We can narrow down the response states to these 4:
- success (2xx) isHTTPSucessful = true
- Validation errors (422) hasValidationError = true
- Server error (500) hasServerError = true
- 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.
https://github.com/erkie/ApiModel/pull/31 addresses this