OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
https://openapi-generator.tech
Apache License 2.0
21.23k stars 6.43k forks source link

[REQ][csharp-netcore] Extract fixed Client code bits to library #2925

Open mboogerd opened 5 years ago

mboogerd commented 5 years ago

Problem

Within one of my services, I access multiple APIs. When generating code for these APIs, a Client package is generated for each of them. This package contains classes that only vary in a few comment lines and default values for Configuration parameters. We end up with many classes/interfaces such as HttpMethod, that are isomorphic yet incompatible across Client packages.

Proposal

  1. Put the Client package under a fixed package (OpenAPI?) instead of the parameterised one.
  2. Extract that package into a library and eliminate it as part of the code-generation output
  3. Import the library from the generated project file
  4. Generate a [API]Configuration class that extends the current Client.Configuration class and provides the generated defaults for the upper class, such as basePath.

Alternatively

  1. Introduce a separate clientPackage code-gen parameter that allows overriding the package where the Client files will be placed
  2. Eliminate the API specific comments in Client package, as well as the default values in the Configuration class
  3. Generate a [API]Configuration class that extends ${clientPackage}.Configuration class and provides the generated defaults for the upper class, such as basePath.
etherealjoy commented 5 years ago

@jimschubert @wing328 I think we could create this with switches. I also have similar issues. This is a necessity when there are multiplie rest clients in the solution It should be possible to specify the model package/project, client package/project and api package/project. This is the same strategy for java spring.

The goal being that the model can be used in controller and in a dedicated project running background logic and in the api.

so the netcore asp server and the netcore rest client can share data via an intermediate business logic without messing up with the dependecy chain. the multiple rest api client also need not have duplicated client/configuration packages