API v2 handles [binary parameter]=any differently from v1

Bug Reports
1

v2 seems to have some sort of validation mechanism to make sure user-input parameter values match allowable values (as defined in Swagger?). generally, that seems like a good thing, except that the allowable value definitions seem to not match what has actually been allowed in the past in some cases – specifically for what we would normally think of as binary parameters.

for example, here’s how verifiable is defined in GET /observations:

conceptually, this accurately reflects the binary nature of the parameter, except that historically, v1 has also accepted any as a valid input for true/false parameters. (=any would return both =true and =false values.)

but compare the following results. v1 returns all observations, while v2 returns an error:

  1. GET https://api.inaturalist.org/v1/observations?verifiable=any&per_page=0 :
    {"total_results":363638330,"page":1,"per_page":0,"results":[]}

  2. GET https://api.inaturalist.org/v2/observations?verifiable=any&per_page=0 :
    {"status":422,"errors":[{"path":"verifiable","message":"must be equal to one of the allowed values","instancePath":"/verifiable","params":{"allowedValues":["true","false"]}}]}

since the default when verifiable is not used is effectively verifiable=any, one might be tempted to say that you could just exclude verifiable=any altogether. however:

  1. even when you can just exclude altogether, it can be inconvenient. for example, suppose you have start with this URL for the Explore page: https://www.inaturalist.org/observations?verifiable=any&user_id=pisum. historically, you could have copied the parameters from that URL and used those directly in an API request URL: GET https://api.inaturalist.org/v1/observations?verifiable=any&user_id=pisum. but since v2 won’t accept verifiable=any, you’d have to do extra work to remove the parameter when creating a request URL for v2: GET https://api.inaturalist.org/v2/observations?usser_id=pisum.

  2. not every parameter effectively defaults to =any as the default when it’s not used. for example, GET /taxa effectively defaults to GET /taxa?is_active=true. this means that in v1, the way to get all taxa (both active and inactive) is to GET https://api.inaturalist.org/v1/taxa?is_active=any, but you get an error if you try that in v2: GET https://api.inaturalist.org/v2/taxa?is_active=any. so right now, you’d have to GET https://api.inaturalist.org/v2/taxa?is_active=true and GET https://api.inaturalist.org/v2/taxa?is_active=false, and then merge the results.

so to get back the same sort of functionality that was available in v1, maybe the definitions (at least for v2) for binary parameters need to be updated to include an any option.