OpenApiTool generator server project impls don't respond with json payload

[barchetta]

We have some inconsistencies with how the ServiceImpl classes in the generated server projects handle JSON (and other media types for that matter) in responses. In my case I used the openapi spec produced by the Helidon quickstart.

• The server MP project has @Produces({ "application/json" }), but responds with a string
• The server SE project responds with HTTP_CODE_NOT_IMPLEMENTED

The first seems wrong and the second seems not-too-helpful. Tim and I discussed a couple options (there might be more):

1. Keep it simple and just respond with NOT_IMPLEMENTED like the server SE project
2. Special case JSON and maybe plaintext and have the Impls return the correct payload type

[tjquinno]

Of course, the OpenAPI spec allows any response media type. The generator as a whole has some nice features for supporting application/json (e.g., the serializationLibrary setting). Our server generators do not need to create example output for every possible media type, but handling JSON and text would generate server projects that would work out-of-the-box while also illustrating the patterns developers might follow when they implement the actual business logic.

Some thoughts:

application/json

In many real-life cases, the OpenAPI definition for the endpoint uses a POJO class as the payload. Ideally, our server generators would detect that and generated code to instantiate the correct POJO class and then set the response content by passing that POJO instance.

This is especially nice because it keeps the generated code (and, by implication, the developer's business logic) agnostic about which serialization library the user selected.

We would need to look at other ways that the OpenAPI definition might indicate the response and decide which other ways (if any) to cover in generating the code.

text/plain

Nothing fancy is needed here. Just emit some hard-coded string as the response payload.

anything else

Return NOT_IMPLEMENTED for the HTTP status.

---

Generating reasonable example data for the response will become more complicated as we add support for multi-part. That said, creating "dummy" return data for that case could follow the same approach; depending on the data type specified for each part of the response, the generator would create code to manufacture dummy parts and then send the parts as a multipart entity back to the client. (Obviously there are plenty of details to be figured out here.)