[Ruby] fix documentation with apikey name

[maximevct]

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh
  

  (For Windows users, please run the script in Git BASH)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.
• File the PR against the correct branch: master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

Hi,
After PR #19740, I forgot to update the documentation generated as the code is generated.
I checked every occurences, should be all

@wing328

[wing328]

lgtm. thanks for the follow-up PR

[s-xu-wafios]

This feature confuses me somehow.
Assume we have the following OAS:

components:
  securitySchemes:
    ApiAuthorizer:
      type: apiKey
      name: Authorization
      in: header

Previously, I simply need to run config.api_key['ApiAuthorizer'] = 'auth_token_value' to set the value, but now I need to run config.api_key['Authorization'] = 'auth_token_value'.

The previous behavior seems more intuitive to me, because this is the way to use "api key". The current behavior is like we are simply setting a "header"

[wing328]

@s-xu-wafios thanks for the feedback

@maximevct can you please review the feedback from @s-xu-wafios when you've time?

[maximevct]

@s-xu-wafios in the sepcs of open API you can see that the name of the header used is the one in the hash and not the key of the hash. Open api Doc

I give you that there is no usefull example in the doc but you can find one in Swagger implementation here : Doc Swagger

openapi: 3.0.4
---
# 1) Define the key name and location
components:
  securitySchemes:
    ApiKeyAuth: # arbitrary name for the security scheme
      type: apiKey
      in: header # can be "header", "query" or "cookie"
      name: X-API-KEY # name of the header, query parameter or cookie

# 2) Apply the API key globally to all operations
security:
  - ApiKeyAuth: [] # use the same name as under securitySchemes

In the example here, securitySchemes key is useless. IMHO, your client using the SDK should not be aware of the internal name of your configuration, only the name of the header to use

[s-xu-wafios]

Hi @maximevct , thanks for the quick reply! Exactly like you have mentioned, the discussion here is if the client should be aware of the internal name.
I have also checked the generated Kotlin client, it also refers to the "name" and not the "key". So the behavior of the generated code is consistent here.

Thanks for the clarification