openaq / openaq-api-v2

OpenAQ API
https://api.openaq.org
39 stars 9 forks source link

Returning string instead of JSON when error validating API parameters #328

Open surfcoders opened 5 months ago

surfcoders commented 5 months ago

Discovered this in v3-alpha, but same thing happens in v2:

When making the following API call with an erroneous parameter (for example limit=-200):

https://api.openaq.org/v3/countries?limit=-200&page=1

It correctly returns an error object as described in the documentation:

{ "detail": [ { "type": "greater_than", "loc": [ "query", "limit" ], "msg": "Input should be greater than 0", "input": -200, "ctx": { "gt": 0 }, "url": "https://errors.pydantic.dev/2.1.2/v/greater_than" } ] }

But when making a call with a different erroneous parameter like:

https://api.openaq.org/v3/countries?limit=null&page=1

It returns as a string:

"[{'type': 'int_parsing', 'loc': ('query', 'limit'), 'msg': 'Input should be a valid integer, unable to parse string as an integer', 'input': 'null', 'url': 'https://errors.pydantic.dev/2.1.2/v/int_parsing'}]"

In addition if not returning a JSON object, I found that:

  1. It does not follow the JSON error response pattern as shown above, and
  2. The 'loc' key returns the correct values, but not as an array ( should be 'loc': ['query', 'limit'] instead of 'loc': ('query', 'limit'))

Thanks in advance

russbiggs commented 5 months ago

Thanks this is related to #300. These errors are essentially what is returned by Pydantic, which we use for schema validation. Ideally these shouldnt be exposed directly, but instead reshaped to be a bit more consumer friendly. Either way the JSON vs string is odd. Ill take a look, but more than likely ill jut wrap these into a better JSON payload instead of the error directly

surfcoders commented 5 months ago

Thanks. Keep us posted. I did a workaround to accommodate this. But the string payload cannot be converted to JSON because of using "( )" to represent an array, when it should be "[ ]"