Abstract away inconsistency of empty results #17
Milestone
Comments
markembling
added a commit
that referenced
this issue
Apr 21, 2019
RequestExecutor is now tested (apart from some async behaviour which is still outstanding). When dealing with a collection as the return type for the request, if null is receieved from the server, an empty collection of the appropriate type is returned instead. This fixes #17.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the API returns
nullfor some query endpoints where no results/matches exist, and for others it returns[]. This can't be changed for backwards-compatibility reasons (see ideal-postcodes/postcodes.io#319).However it makes sense in the context of this client to abstract that away and handle empties in a more predictable way (i.e. always returning an empty
IEnumerable<T>). This will be more consistent for devs using this client library. This will be a backwards-incompatible change, so needs to tie to v1.x.The ability to opt out of normalising empty results and back into API-consistent behaviour (3a/3b in the linked discussion, where results will come back as
nullwhere the API gives that) should probably also be added.The text was updated successfully, but these errors were encountered: