Hello all, If you're interested in steering the di...
# ktor
b
Hello all, If you're interested in steering the direction of Ktor's future in OpenAPI support, please consider reviewing the current draft proposal: https://github.com/ktorio/ktor-klip/pull/3 Other new feature proposals for Ktor will flow through this repository, so ensure to subscribe if you're interested in seeing what's in the pipeline.
🔥 3
kodee loving 2
K 4
a
This is openapi output support which is great. An official OpenAPI client generator would also be great. The current state of opensource libraries isnt great.
h
@Arjan van Wieringen See https://github.com/hfhbd/kfx for OpenAPI client/server code generator.
IMHO we should reuse/extend the Resources plugin to only have one type safe option to specify routes including parameters and body’s. And a route registered with a Resource requires the type in the resource to be returned.
👍 1
h
I'm interested is there a sample to see authenticated routes, how they are handled?
a
@hfhbd great. That is 0.0.9 though ;) so how confident should I be using that in production?
h
@Arjan van Wieringen well, try it out. The biggest refactoring I need to to before 1.0.0 is the error handling. Currently, I subclass the error class from Error and throw it, but that does not work with a list of errors returned by an API. So I think I will remove the subclass and the throwing. But anything else is very stable.
a
@hfhbd Thanks! I definitely will.
b
This is openapi output support which is great. An official OpenAPI client generator would also be great. The current state of opensource libraries isnt great.
The tooling provided by kfx and other libraries is pretty good atm so it's not as high of a priority. I think it makes sense to generate clients from specs to close the loop here, so we'll eventually try to get something official.
IMHO we should reuse/extend the Resources plugin to only have one option type safe option to specify routes including parameters and body’s. And a route registered with a Resource requires the type in the resource to be returned.
We're going to provide support for the Resources API and will look into providing a new routing API (or extending Resources) for a later release that will be a better fit for mapping to OpenAPI.
I'm interested is there a sample to see authenticated routes, how they are handled?
I'll investigate this further and include details in the document.
1
a
Are you going to provide a way to specify also examples for the OpenAPI documentation?
b
Yes, good point, I'll look into it and include something in the doc. It might be a little tricky with complex types.