The current state of error-handling leaves some to be desired. A given input passes through two transforms: first, into a set of geocoded coordinates; and second, to a forecast. Failed geocoder lookups are handled by returning an empty HTTP 400 Bad Request response, but this covers only "typical" failed lookups, where the geocoder behaves correctly but the lookup fails. More esoteric failures are largely unhandled. Errors are barely considered for the forecast lookup, and the function of the API is reliant on coordinates consistently returning a forecast.
In sum, I'm certain a round of solid QA would unearth a bevy of edge/corner cases in need of elegant error-handling.
The current state of error-handling leaves some to be desired. A given input passes through two transforms: first, into a set of geocoded coordinates; and second, to a forecast. Failed geocoder lookups are handled by returning an empty HTTP 400 Bad Request response, but this covers only "typical" failed lookups, where the geocoder behaves correctly but the lookup fails. More esoteric failures are largely unhandled. Errors are barely considered for the forecast lookup, and the function of the API is reliant on coordinates consistently returning a forecast.
In sum, I'm certain a round of solid QA would unearth a bevy of edge/corner cases in need of elegant error-handling.