Craig Heneveld
Craig Heneveld
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...
https://github.com/erkie/ApiModel/pull/31 addresses this
https://github.com/erkie/ApiModel/pull/31makes a clear distinction between the types of errors
The nil option isn't meaningful enough. Is the backend down? Did the path change? What happened? I like the idea of standardizing all the calls and passing meaningful error/response objects...
https://github.com/erkie/ApiModel/pull/31 addresses this question. Find methods now take apiModelResponse as a parameter, and objects will be nil if "server" errors occur
https://github.com/erkie/ApiModel/pull/24 has some more tests, including a stub framework for networking.
I believe if you have partitioning on you are stuck with using id as the key. A feature request could involve using the hash_key as the partitioned key instead of...
I found this the case just for SCANs. Works great on QUERY requests.