Hi channel! :wave: We recently released <a protot...

# ktor

[Anton Yalyshev [JB]]

Hi channel! 👋

We recently released a prototype of _OpenAPI spec generation support_.
Before we move forward, we really need your feedback to make sure this feature works well for your use cases.

👉 Please try it out and fill in this short survey, even if everything worked well for you.
Your feedback will directly shape the future of this feature 💜

[Arjan van Wieringen]

The big question I have is why we use comments for the “annotations”. Kotlin is super expressive, and using comments for this feels like a misuse of comments and pretty hacky.

[Anton Yalyshev [JB]]

cc @Bruce Hamilton @simon.vergauwen

[simon.vergauwen]

The bodies of the routes are introspected during compile them and it automatically picks up on HttpStatusCodes, return types, ContentType, path, query parameters, security, etc.

However that still leaves documentation. All those values can have a description field in the OpenAPI documentation (and potentially other formats like Smithy or Typespec). KDoc feels like a natural solution for actual documenting just like you would use @param name description to add a description to the API documentation. Ktor will now support @path name description, @query name description, etc.

Does it make more sense to you that way @Arjan van Wieringen? Alternatively seems to be overloading all the Routing DSL functions with a description: String field/parameter.

[Arjan van Wieringen]

Ah that makes more sense.