Update API generation with openapi-generator (kotlin/multiplatform instead of Kotlin/jvm)

[ATchernov]

We use OpenAPI generator to generate ktor-client code from openapi. In openapi-generator 4.1.3 was added multiplatform support - https://github.com/OpenAPITools/openapi-generator/pull/3900. Now we should check differences between openapi-generator code and our. Then if code simmilar, or differences is small - we should move to use openapi-generator kotlin-multiplatform version.

If in generator used old version of ktor-client/serialization/coroutines - we should create fork of openapi-generator, make update and create pull request to openapi-generator. After it moko-network should just simplify multiplatform generation setup, but not add new generator templates.

links: https://openapi-generator.tech/docs/generators/kotlin

[shadowsheep1]

@ATchernov the problem is that you still support only 1.3.50 version of kotlin. You need to update the kotlin-multiplatform generator to address the new kotlin versions and maintain that in a faster way [-;

[Alex009]

@shadowsheep1 moko-network use 1.3.70, what do you mean about 1.3.50?

[shadowsheep1]

Hey @ATchernov didn't see you're a moko-network contrib, thinking you were from openapi plugin, sorry. Moko is great 'casue it follows tight kotlin version releases, while the openapi client gen is stuck on 1.3.50. https://github.com/OpenAPITools/openapi-generator/blob/master/docs/generators/kotlin.md https://github.com/OpenAPITools/openapi-generator/issues/5346

At a first look, you differ from the kotlin-multiplatform version

--library multiplatform

java -jar openapi-generator-cli-4.2.2.jar generate -g kotlin -p packageName=it.shadowsheep.mpp.app.client --library multiplatform --additional-properties nonPublicApi=true -i openapi.yaml -o open_mpp

of openapi-client client gen because you return the Model and not the HttpResponse<Model>of the model.

This way how do you propagate http response status code and headers? This info should be useful.

/cc @Alex009

[Alex009]

in our usecases we not read response headers yet and do status code checks only in ErrorFeature (if status code not successful then this feature try create exception for this case). i think it will be good if we add HttpResponse<Model> case in generation, in addition to already exists methods

[Alex009]

required usecase - reading of headers in response

[shadowsheep1]

Another use case is that we have response status code with a deeper meaning (read custom meaning) so that we act in some way when we have a particular status code.