Empty search does not return descriptive message

Development

AI-generated summary

A bug has been reported in the API search endpoint, where an empty search query returns a JSON object with a NULL value and a 200 status, instead of a descriptive error message and a 400 status. The Front-End correctly validates the search term, but the API only partially validates it, allowing empty searches to go through. heyallan suggests that the API should respond with a descriptive error message, similar to the expected response:

{
  "errors": [ "You supplied invalid parameters to the request: q" ],
  "error_type": "invalid_parameters"
}

sam notes that the search route allows for multiple arguments and that caution is needed when treating min_search_term_length as a requirement. heyallan provides an overview of the issue, highlighting the inconsistencies in validation and documentation, and believes this is a bug rather than intended behavior.

1

The Front-End does not allow empty search and displays a helpful message explaining the search term is too short.

However, the API endpoint still allows empty search but the response is a JSON object with a NULL value and 200 status.

Shouldn’t the API respond with a descriptive error message and a 400 status?

Expected:

// 400 error
{
  "errors": [ "You supplied invalid parameters to the request: q" ],
  "error_type": "invalid_parameters"
}

Actual:

// 200 ok
{
  "grouped_search_result": null
}
2

The API should certainly can be improved here, but the query route allows for a lot of args:

We would need to be very careful here to check one we treat min_search_term_length as a requirement vs an optional thing.

3

Thanks @sam

As it stands:

  • Empty search is a dead spot in the API
  • Search endpoint accepts a search term but also metadata arguments (user, categories, tags, etc.)
  • Metadata arguments are not documented in the API
  • Front-end validates the search correctly, but back-end API validates it partially (allowing empty search to go through)
  • Response message should be descriptive in any case

I hope this overview helps.
IMO this a bug. I’d be surprised if this is the intended behavior.
Thanks anyway :v: