Added Code Generator For Ruby (Faraday)

[AcousticDeveloper]

PR Description

This PR adds automated code generation for Ruby's Faraday library and also tests the generated code.

Related Issues

• Related Issue #147
• Closes #147

Checklist

• [x] I have gone through the contributing guide
• [x] I have updated my branch and synced it with project main branch before making this PR
• [x] I have run the tests (flutter test) and all tests are passing

Added/updated tests?

• [x] Yes, I have added and tested all the test cases and the generated code behaves as expected.

Instructions to run the generated code in local computer

1. Install ruby and setup path so that ruby and gem executable are available.
2. Run

   gem install bundler

   to install bundle as a command line tool.

3. Inside a directory create one GemFile and main.rb file.
4. Add faraday as mentioned in the Documentation and Faraday Multipart for sending multipart form requests. Add them inside the GemFile along with one source attribute at the top of the GemFile. Then run

   bundle install

   to install the dependencies.

5. Copy the generated code inside main.rb file.
6. Run ruby ./main.rb to run the generated code.

Note: For HEAD 2 test case, the initial response has status code 301 but faraday_middleware gem, which was previously required for following redirections, is deprecated and a curated list has been published under awesome-faraday by the maintainers. The redirection middleware is now bundled as it's own gem faraday-follow-redirects which is an external dependency which I have not included in code generator.

I wish to add that after discussing that with maintainers. Integrating redirection following is mentioned in the documentation as and can be achieved by adding the faraday.response :follow_redirects statement above adapter setup.

Along with that, we need to add the require statement with the existing require statements so that the respective code is imported.

Thus currently running generated code for HEAD 2 returns 301 but API Dash returns 405, which can be modified accordingly for both to return 405 and get the desired output of the user. If required, I am willing to add the support for redirection and modify the required code.

[animator]

Thanks for the PR

[AcousticDeveloper]

Thanks for the PR

You are welcome @animator . I had a query though. I was reviewing the changes made to the PR before getting merged, and saw that application/x-www-form-urlencoded content type header setup was removed. I wanted to ask whether this should be totally avoided from next time onwards and #337 should be used to set it up automatically? In that case, I'll try to fix #337 before raising any other code generator PRs.

Regarding the implementation, as far as I could understand, the content type is set using the dropdown for text/json/formdata.

So I think there are two ways to fix the issue, either we can restrict the use of requestModel.requestBodyContentType.header in code generators as this value is directly set while creating the enum.

Instead we can use a custom requestModel.getContentTypeString() method (yet to be implemented) which can generate the string depending upon request model contents. Or we can follow a more Postman centric approach by giving the users a separate window for application/x-www-url-encoded body type.

PS: We can further discuss about the approaches under #377.

Thanks again for merging the PR.