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:

https://github.com/DeepLcom/openapi/blob/189588784d656ca8937ee68590a474eb248cc038/openapi.yaml#L593-L606

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)