When specifying a list of dataset names with dataset_name__in, API returns 400 Bad Request if any of the names don't exist

[brlodi]

This is potentially not a bug, but is certainly a nomenclature issue.

Endpoints which accept dataset_name__in return a HTTP 400 Bad Request error if the passed list contains dataset names that don't exist or aren't the correct type. For example, .../timeseries?dataset_name__in=311_service_requests_rodent_baiting,foo and .../timeseries?dataset_name__in=311_service_requests_rodent_baiting,major_streets both trigger the error response, in the first case because foo isn't the name of any dataset and in the second because major_streets does exist but is a shape dataset.

From a semantic perspective, I would not expect dataset_name__in to need to only contain extant datasets of the correct type. The parameter reads as an in expression and so it is reasonable to expect it to carry the same semantics as in does in other cases:

Python

>>> 'a' in ['a', 'b', 'c']
True

Javascript

> 'b' in { a: 'foo', b: 'bar', c: 'baz' }
< true

Although I think there is utility in supporting the common understanding of in here, I recognize that the current behavior is likely much more performant. If we want to keep this implementation, however, I think this needs a different name with less confusing semantics (possibly as simple as a pluralized dataset_names field).

Relatedly, this is another apparent misuse of the HTTP 400 Bad Request error by the API. There is nothing wrong with the syntax of the HTTP request. Backend errors should not be arbitrarily mapped to HTTP status codes, which serve a specific purpose in governing the network communication. (I don't think this is a "bad request" anyway, since it's a value error not a structural one)