Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Java][okhttp-gson] Add option to employ builders for API requests #1341

Merged
merged 23 commits into from
Nov 28, 2018

Conversation

Kiran-Sivakumar
Copy link
Contributor

@Kiran-Sivakumar Kiran-Sivakumar commented Oct 30, 2018

PR checklist

  • Read the contribution guidelines.
  • Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh and ./bin/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
  • Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
  • Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@bbdouglas @JFCote @sreeshas @jfiala @lukoyanov @cbornet @jeff9finger

Description of the PR

fix #1217
This PR (filed against branch 3.4.x) adds the option to generate APIs of the form shown in the proposed solution in the above issue. This makes generated okhttp-gson clients much nicer to use, especially in cases involving unused optional parameters. The hope is to implement a similar solution for all Java generators in the future, so that generated Java clients aren't frustrating to use.

Changes:

  • JavaClientCodegen.java modified to add a new CLI option "useBuildersForApiRequests" (default: false)
  • okhttp-gson/api.mustache
    • Optionally generate API-request builders
    • Change original methods from "public" to "private" if builders are generated, since user will want to use the public builder methods instead (the builder methods simply wrap around the original methods that take all parameters as input)
    • Generate comments
  • okhttp-gson/api_test.mustache added to generate tests that use the builders if the "useBuildersForApiRequests" option is enabled
  • bin/java-petstore-okhttp-gson-builders.sh added to generate petstore samples with API-request builders (added one for Windows as well)
  • samples/client/petstore/java/okhttp-gson-requestBuilders/: new petstore samples generated with the above script
  • docs/generators/java.md updated with new config option

I also ran the original shell scripts under ./bin/ to ensure that absolutely nothing changes in the existing petstore samples when the "useBuildersForApiRequests" option is disabled.

@Kiran-Sivakumar Kiran-Sivakumar changed the title [Java][okhttp-gson] Add option to employ request builder for much nicer APIs [Java][okhttp-gson] Add option to employ builders for API requests Oct 30, 2018
@@ -146,6 +146,9 @@ CONFIG OPTIONS for java
feignVersion
Version of OpenFeign: '10.x', '9.x' (default) (Default: false)

useBuildersForApiRequests
Generate API that does not require specifying unused optional parameters when making requests with the okhttp-gson library (Default: false)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would set it to true by default

@@ -63,6 +63,7 @@
public static final String FEIGN_VERSION = "feignVersion";
public static final String PARCELABLE_MODEL = "parcelableModel";
public static final String USE_RUNTIME_EXCEPTION = "useRuntimeException";
public static final String USE_BUILDERS_FOR_API_REQUESTS = "useBuildersForApiRequests";
Copy link
Member

@cbornet cbornet Oct 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too many options 😢

@cbornet
Copy link
Member

cbornet commented Oct 30, 2018

As always, I'm reluctant to have too many options. So I would prefer to always generate the builder, keep the constructors public and have a way to encourage users to move to the builder style (eg. setting the constructor @Deprecated and adding a comment that future version will set it as private. Then in a minor release or 2, we can completely switch to private.

@Kiran-Sivakumar
Copy link
Contributor Author

Kiran-Sivakumar commented Oct 30, 2018

@cbornet Thanks for your feedback. I agree that too many options can be undesirable. Perhaps the option can be removed in the next major release (to only generate the builder style)? Otherwise, I can incorporate your proposed changes. This would require the public builder method name to be changed, however, to not conflict with one of the current method names.

@wing328
Copy link
Member

wing328 commented Oct 30, 2018

@Kiran-Sivakumar @cbornet FYI. next major version 4.x (with breaking changes) will be released before year-end so we can clean up the options as part of the 4.x release later.

@Kiran-Sivakumar
Copy link
Contributor Author

Ok, so should I keep it as an option for this PR, changing it to be true by default, and file another PR against 4.x in a few weeks that removes the option entirely?

@wing328
Copy link
Member

wing328 commented Oct 31, 2018

@Kiran-Sivakumar I've other ideas. Let me review and get back to you by Thursday.

@wing328
Copy link
Member

wing328 commented Nov 1, 2018

@Kiran-Sivakumar instead of using useBuildersForApiRequests in the templates, what about using x-group-parameters vendor extensions like what I did for PHP in https://github.com/OpenAPITools/openapi-generator/pull/1337/files#diff-076573ccfdac2ab5af4dc1813e5ccee3R92?

This will avoid another option and make it possible to enable group parameters per operation.

@Kiran-Sivakumar
Copy link
Contributor Author

Kiran-Sivakumar commented Nov 1, 2018

I see. What if you wanted to enable builders for all operations for a cohesive API? Is there an easy way to apply group parameters to all of them?

@wing328
Copy link
Member

wing328 commented Nov 2, 2018

@Kiran-Sivakumar similar to what we did for consumes, produces (global vs local), if x-group-parameters is defined in the top level of the spec, we will add x-group-parameters to all operations in postProcessOperationsAndModel (only if x-group-parameters is not defined in the operation level).

Does it sound good to you?

@Kiran-Sivakumar
Copy link
Contributor Author

Oh great. Yes, this sounds good to me. I'll incorporate your feedback.

@wing328
Copy link
Member

wing328 commented Nov 9, 2018

@Kiran-Sivakumar I've filed #1405 to add top level x-group-parameters support.

@Kiran-Sivakumar Kiran-Sivakumar changed the base branch from 3.4.x to master November 9, 2018 19:29
@Kiran-Sivakumar Kiran-Sivakumar changed the base branch from master to 3.4.x November 9, 2018 19:30
@Kiran-Sivakumar Kiran-Sivakumar changed the base branch from 3.4.x to master November 9, 2018 20:03
@wing328 wing328 modified the milestones: 3.3.3, 3.3.4 Nov 14, 2018
@Kiran-Sivakumar
Copy link
Contributor Author

@cbornet @wing328 I have incorporated your feedback.

@wing328 wing328 merged commit 9df7079 into OpenAPITools:master Nov 28, 2018
@wing328
Copy link
Member

wing328 commented Dec 4, 2018

@Kiran-Sivakumar thanks for the PR, which has been included in the v3.3.4 release: https://twitter.com/oas_generator/status/1068772409795207168

A-Joshi pushed a commit to ihsmarkitoss/openapi-generator that referenced this pull request Feb 27, 2019
…penAPITools#1341)

* Generate APIs that use the builder pattern

* Add option to use builders for API requests

* Fix template spacing

* Add new sample-generation script and generated samples

* Update docs

* Add new sample-generation script for Windows

* Replace config option with vendor extension

* Remove useBuildersForApiRequests config option

* Remove builders sample-generation scripts

* Replace config option with vendor extension in api_test template

* Remove okhttp-gson-requestBuilders sample

* Rename x-builders-for-api-requests to x-group-parameters

* Add modified api_doc.mustache under okhttp-gson resources

* Add modified README.mustache under okhttp-gson resources

* Update petstore samples

* Fix FakeApiTest.java in petstore samples

* Add whitespace to rerun checks

* Remove whitespace to rerun tests

* Fix FakeApiTest.java in parcelable petstore sample

* Update versions in samples

* Update versions in samples
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Java] Generated Java APIs often have too many method parameters
3 participants