OpenAPITools / OpenAPITools/openapi-generator
[REQ][Perl] Refactor rquests in ApiClient.mustache
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
Is your feature request related to a problem? Please describe.
This refactor would be to address maintainability and performance, without changing any business logic or interface logic.
Swap LWP::UserAgent for HTTP::Tiny
HTTP::Tiny has been core module since 5.013009:
This is a very simple HTTP/1.1 client, designed for doing simple requests without the overhead of a large framework like LWP::UserAgent.
This would also eliminate the need for the following non-core modules:
- HTTP::Request::Common
- URI::Query
- URI::Escape
As well, HTTP::Tiny provides a request() method that could improve the conditional logic in call_api() around HTTP methods.
Support SSL
Unless I am overlooking it, I don't believe LWP has been installed with dependencies that support SSL, i.e. LWP::Protocol::https, Net::SSLeay, IO::Socket::SSL, etc.
Leverage JSON::MaybeXS/etc instead of JSON
Depending on the API, there could be some notable performance improvements by using Cpanel::JSON::XS or JSON::XS
Scalar::Util included but not used
Scalar::Util is not used, and honestly, I don't see a huge need for it besides preference. This could be dropped entirely
Describe the solution you'd like
Noted above.
Describe alternatives you've considered
N/A
Additional context
None.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ApiClient.mustache and the call_api() entry point, then inspect the generated Perl client dependencies. Compare the current LWP::UserAgent, JSON, Scalar::Util, and related module usage with the proposed HTTP::Tiny and JSON alternatives. Done means preserving business and interface behavior while removing unused or unnecessary non-core dependencies, including SSL support where required.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- perl
- Domain
- tooling
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100