Context: Historically, Wikibase software has allowed statement IDs that had Q-ID (or P-ID) part lowercased. It has resulted e.g. on Wikidata to have statements in mixed case, e.g. q7348050$F81E10C9-8F35-4F21-9057-BE76C1E0AB5A and Q7348050$6252EE3A-D5AC-45D7-9A41-85D4087AB6D9 on the same item.
As the statement ID is used to identify it, in REST API but also in other Wikibase interfaces, Wikibase REST API cannot stop handling those.

As a Wikidata editor operating a Wikibase REST API client I want to access data of a statement on an item regardless of the specific ID case used in Wikidata database, so that I can easily get access to the data and use it in my gadget.

Intended solution would be to treat the input statement ID as "case insensitive", in the sense that, as long as we can determine it, for GET requests for statement data using statement ID, the Wikibase REST API responds

1. If the "spelling" of the statement ID used in Wikibase matches the one in response: with a regular HTTP 200 response providing statement data, as it has done so far
2. if there is with a statement on the item/property that matches the provided statement ID but with different case of character: with a HTTP 308 response pointing to URL using the "actual" statement ID
3. if there is no statement on the item/property with the given ID, regardless of the case of characters: with the HTTP 404 response as it does currently

Task Breakdown Notes

• Create a new response middleware (see AuthenticationMiddlewarefor an example) that inspects only "statement not found" error responses
• retrieve the list of all statements of the requested statement's subject using EntityLookup
• iterate over all statements and try to find the statement by its case-insensitive statement id from the request
  • return 308 redirect with Location: header if found
  • return original 404 error response if really really not found