-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
[Ruby] add support for "faraday" #3405
Conversation
# | ||
# @return [Array<(Object, Integer, Hash)>] an array of 3 elements: | ||
# the data deserialized from response body (could be nil), response status code and response headers. | ||
def call_api(http_method, path, opts = {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This template is very similar to api_client.mastache. The main difference is the implementation of call_api() and build_request(). Would it make sense to combine the two templates and simply pick the implementation of these methods based on the library selected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is ~400 lines. Keeping both templates in sync when changes happen outside those methods will be a PITA I think.
So I'd say for long term maintainability, it makes sense to merge them but I'm an outsider of this project, I hope maintainers can chime in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The generator supports a library
option, which allows library specific overrides for individual files. Using this may make the logic and template separation clearer. The Java client generator is a good example. Let us know if you'd like to move toward that option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think there's a library option added by this PR:
so the other 2 options (Ruby HTTP library names) are not needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This template is very similar to api_client.mastache
I'll see if I can combine the two ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think there's a library option added by this PR:
so the other 2 options (Ruby HTTP library names) are not needed
Makes sense. I'll remove them.
# @return [Array<(Object, Integer, Hash)>] an array of 3 elements: | ||
# the data deserialized from response body (could be nil), response status code and response headers. | ||
def call_api(http_method, path, opts = {}) | ||
connection = Faraday.new(:url => config.base_url) do |conn| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dkliban Thanks so much for this PR!
I wonder if you have considered how to add middlewares here to fully use the power of Faraday. One could add caching or tracing or whatever in here. I think that's one of the best things about moving to Faraday
response.reason_phrase | ||
end | ||
end | ||
rescue Faraday::TimeoutError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm torn about making all failign cases the same Exception class, it may be difficult to distinguish among errors if that's what the caller wants to do. Also here you probably want to deal with Net::ReadTimeout
and Faraday::ConnectionFailed
Solution: add support for Faraday library This patch builds on the work started by @meganemura
d13f4de
to
585d5c9
Compare
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
Solution: switch ruby client to use Faraday This patch relies on a forked version of the openapi-generator-cli. Once the PR that introduces this functionality is merged into openapi-generator, the ruby client generation should be switched back to using the docker container for openapi-generator. OpenAPITools/openapi-generator#3405 Required PR: pulp/pulpcore#226 re: #4896 https://pulp.plan.io/issues/4896
...es/openapi-generator/src/main/java/org/openapitools/codegen/languages/RubyClientCodegen.java
Outdated
Show resolved
Hide resolved
...es/openapi-generator/src/main/java/org/openapitools/codegen/languages/RubyClientCodegen.java
Show resolved
Hide resolved
CliOption libraryOption = new CliOption(CodegenConstants.LIBRARY, "HTTP library template (sub-template) to use"); | ||
libraryOption.setEnum(supportedLibraries); | ||
// set FARADAY as the default | ||
libraryOption.setDefault(FARADAY); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using Faraday as the default later (say 4.2.0) after we collect more feedback from the users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be great.
...es/openapi-generator/src/main/java/org/openapitools/codegen/languages/RubyClientCodegen.java
Outdated
Show resolved
Hide resolved
Solution: Make Typhoeus default This patch also updates the api_client template for Faraday to include query params with requests.
4006ade
to
b708032
Compare
@@ -0,0 +1,5 @@ | |||
{ | |||
"gemName": "petstore", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think typhoeus
is the default so we need to add "library": "faraday",
here if I'm not mistaken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take care of it in another PR.
I've filed #3520 for various improvements |
Description of the PR
This patch adds ability to specify which library to use when generating a Ruby Client. The two options are 'typhoeus' and 'faraday'. The implementation with 'typhoeus' was already present and this patch adds support for 'faraday'.
I have not tested this with the SSL option or token Auth.
I did test that the client can use basic Auth and perform both JSON and multipart/form-encoded requests.