GET [...]/rest.php/wikibase/v0/search/properties?language=en&q=...
Request parameters (query parameters, both mandatory)

• q - search term
• language - language code

Response structure in pseudo-JSON

{
  "results": [
    {
      "id": "P123",
      "label": { "language": "<LANGUAGE>", "value": "<LABEL value and language it's in>" }
      "description": { "language": "<LANGUAGE>", "value": "<DESCRIPTION value and language it's in>" }
    },
    ...
  ]
}

Response:

• always respond with status code 200, even for an empty result list
• Error handling and validation to be the same as for simple item search
  • mul is not a valid search language code

Not in scope:

• no special treatment of haswbstatement etc "keywords". Pass them as-is
• search results provided in an asynchronous response

In scope:

• including a matched data element in the response
• language fallback of labels or descriptions in the search results
• no hard dependency on Cirrus search extension -- the API should use a simple term store database search, see simple item search

Task breakdown notes:

• OpenAPI schema
• create use case happy path with request and response objects
  • including unit tests
• request validation
• create RouteHandler that makes use of the use case + middlewares
  • including end-to-end test
  • create a SqlTermStoreSearchEngine that works for properties (or adapt the existing one to work for both)
• match data + language fallback
  • this is just a reminder. If T386228 is done first, it might be easiest to just implement these along the way with the happy path etc.
• openapi validation test