API response when term None is requested

[mquantin]

When I request the REST API with (example)
http://localhost/api/resource_classes/ params={'term': None}
As there is no class with None value as term,
the API should give no results.
But It gives me the http://localhost/api/resource_classes/1
(which term is dcterms:Agent FYI)
Strange behaviour... could you fix it?

[zerocrates]

This is Python you're working from? I'm not sure if a None there will send us the string "None" or just a blank for the term parameter.

Anyway I think the behavior you're seeing is just down to the API ignoring term parameters that don't "look like" a valid term (i.e., a string with a colon in the middle), and treat it as if nothing was passed.

[mquantin]

Indeed, it's python (sorry for that imprecision)
But anyway, the strange behaviour is to return something that doesn't match the criteria (here the resource class term).
Continuing your thoughts: no need of "look like" check : when nothing matches, nothing should be returned.

[alexdryden]

Do you have the "results per page" in General Settings set to 1 in your local installation, or are you otherwise only fetching 1 result? If you pass a query parameter of "" or "None" or anything lacking a colon as the value for "term", it should fail the isTerm() check, which validates the input to be a string with a colon in the middle, and would therefore ignore the query parameter altogether and give you all the resource classes.

@zerocrates I tend to agree that it would make more sense and would make the API easier to navigate if an error message was returned when a malformed query fails a validation-like check, for example by having isTerm() checked inside the isset($query['term']) and returning an error message on false. Is that the kind of change you would entertain, or is there another reason to keep it as is?

[zerocrates]

The API generally is purposely tolerant of "empty" arguments as it's simpler to hook that up to an HTML form, so where rejecting empty-string arguments overlaps with some other validation we often take the simple route and treat both the same and just ignore them both.

I don't know also that we're well set up to, for example, return 400 on these at the moment... the systems we otherwise use for reporting and collecting errors aren't used on the query side of the API.

[mquantin]

@alexdryden you got it! thanks
The API returns a whole page of results.
I don't have parameter set to 1 result per page but I truncate the API response after the first result.

I use this method (link to the line in github) of python omeka_s_tools.
The line resource = data['results'][0] is doing the cut!

I understand the design of a tolerant REST API.
I agree, raising an error400 in the header (+ serving default results?) would be nice !