Incorrect Content-Type for /document/{document_id}/result response

[strager]

The current DeepL OpenAPI schema says that responses for /document/{document_id}/result requests have Content-Type: application/octet-stream:

openapi/openapi.yaml

Lines 593 to 606 in 1895887

	responses:
	200:
	description: The document is provided as a download. There is no other data
	included in the response besides the document data. The content type used
	in the response corresponds to the document type.
	content:
	application/octet-stream:
	schema:
	type: string
	format: binary
	examples:
	OK:
	summary: OK
	description: binary document data

However, this does not match my interaction with DeepL's production API server. The API can actually return other Content-Type values such as application/vnd.openxmlformats-officedocument.wordprocessingml.document (for a .docx translation).

Some OpenAPI client generators, such as ogen, assert that the Content-Type matches the specification. The current DeepL OpenAPI schema is not usable with these generators.

I would like the OpenAPI schema to reflect the Content-Type values used in practice if possible.

[strager]

Here is a patch I am using locally to fix this issue:

             included in the response besides the document data. The content type used
             in the response corresponds to the document type.
           content:
-            application/octet-stream:
+            '*/*':
               schema:
                 type: string
                 format: binary

[JanEbbing]

This is a great catch, thanks for the report. I will look into what content types document translation can return and fix this (and think of a way to make this scalable if we add further file types in the future)