Align PublicBody search between views and API

[noeddl]

Search is currently handled differently in regular views and API views, which leads to inconsistent search results depending on whether a search is performed via the search form or through the API.

This is especially the case for PublicBody (see https://github.com/fragdenstaat/issues/issues/293). In the API view, get_searchqueryset is overridden with a custom search and filtering configuration. As a result, recent changes to the search analyzers are not applied there. Using PublicBodyFilterSet instead, as in the view, could resolve this.

However, I noticed several differences between PublicBody search in views and in the API (which is also why the tests I added are currently failing):

• The API uses multi_match search, while the rest of the application appears to use simple_query_string.
• The API filters by IDs, whereas PublicBodyFilterSet uses slugs (which seems to be consistent with other API endpoints, e.g. for FoiRequest).
• The category filter is named categories in the API but category in PublicBodyFilterSet.
• Filters for regions and regions_kind exist in the API, but not in PublicBodyFilterSet.

I’m unsure how to resolve these differences without breaking the API, and which parts are still intentional vs. legacy behaviour.

@stefanw Could you take a look?

[stefanw]

The API uses multi_match search, while the rest of the application appears to use simple_query_string.

Regarding query behaviour via q, I think we can change that in the API to the best consistent behaviour (which one that is, is up to you!). As long as it's the same parameter and it does some kind of search, it's ok.

The API filters by IDs, whereas PublicBodyFilterSet uses slugs (which seems to be consistent with other API endpoints, e.g. for FoiRequest).

Tricky. The original search interface was designed to be 'pretty' (e.g. URLs like https://fragdenstaat.de/anfragen/an/bundesrechnungshof/) but that also made it complicated to maintain and create URLs with more query parameters. The API should be practical, long-term and language-independent, so using IDs seems better. Public body names and slugs change sometimes (e.g. ministry gets a new name) and we may decide to add i18n support. So in the API I would prefer IDs. If this breaks the API, we could look at usage and decide if it's ok.

The category filter is named categories in the API but category in PublicBodyFilterSet.

Let's not change the API parameter name if possible. Public bodies can have multiple categories and it should be possible to filter by multiple categories, so the plural makes sense.

Filters for regions and regions_kind exist in the API, but not in PublicBodyFilterSet.

I think this is mainly because exposing a user interface for these search parameters does not serve a common use cases for web browser users, but for API users it's helpful (I built the feature because I needed it).

If we can have the same search/filter machinery for API and UI while keeping the UI simple and the API stable, let's do it.

[noeddl]

Following up on Stefan's comment, I aimed to unify the implementation as much as possible while still keeping the parts separate that should stay separate.

The main change to the API search is that it now uses the simple_query_string strategy, filters should work just as before both in the API and the UI.

I also removed the old guard that ignored queries shorter than three characters in the API search. If this turns out to cause performance issues, we can always add it back.

[krmax44]

Currently, filters like ?jurisdiction=123456 do result in a 400 error, and I think they should. Does this change that behavior?

[noeddl]

You're right when it comes to the publicbody endpoint. However, the publicbody/search endpoint currently returns an empty list when queried with invalid filter values, and I wanted to preserve that behavior.

I agree that returning a 400 error would be better, and it would also make it consistent with what e.g. the request/search endpoint does.

@stefanw Do you see any reason not to change this?