search

azavea / climate-change-api

Apache License 2.0
0 stars 0 forks source link

Errors should be returned as array #791

Open flibbertigibbet opened 6 years ago

flibbertigibbet commented 6 years ago

Currently, error messages are returned as as the string representation of an array of strings. The array of strings itself should be returned instead.

For example, this staging query returns:

{"error":"[\"J must be one of ['C', 'F', 'K']\"]","help":[ ...

Note the error response array is a string, while the help response array is an array.

rmartz commented 6 years ago

In other endpoints it appears that error is a string, we may want to consider having a consistent structure for our error responses

GET https://app.staging.climate.azavea.com/api/city/nearest/
{
    "error": "lat must be a float"
}
flibbertigibbet commented 6 years ago

Returning as array of strings (or other collection) allows for returning multiple errors. Yes, the format should be consistent.

rmartz commented 6 years ago

Changing a field from a string to a list could be a breaking change, so we should be careful about opting for that route. Do we currently have a place that we would offer more than one error simultaneously? My understanding is most errors are thrown in code, so they're fatal and stop execution immediately - in theory our indicator parameter validators could parse the whole parameter input and make a list, but it appears they currently stop on their first error as well.

Since making this field a list would be a breaking change we don't currently have code in place to take advantage of, perhaps in the future we can make parameter validation a special case that introduces a new error response attribute with the full list of observed failures.