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.