Currently the API returns null for some query endpoints where no results/matches exist, and for others it returns []. This can't be changed for backwards-compatibility reasons (see https://github.com/ideal-postcodes/postcodes.io/issues/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 null where the API gives that) should probably also be added.
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 https://github.com/ideal-postcodes/postcodes.io/issues/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.