fix: schema access failure to https

[shaohuzhang1]

fix: schema access failure to https

[f2c-ci-robot]

Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[f2c-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[shaohuzhang1]

No issues found in the provided code. It correctly implements customizing Swagger generation by setting up tag handling and specifying both HTTP schemes ('http' and 'https'). The CustomOpenAPISchemaGenerator class is defined to extend OpenAPISchemaGenerator, allowing customization of API scheme settings based on HTTPS checks.

[shaohuzhang1]

The provided swagger configuration snippet has no apparent errors or potential issues from a technical standpoint. To suggest optimizations:

1. Customization of Schema Generation: By adding 'DEFAULT_GENERATOR_CLASS' with the value 'common.config.swagger_conf.CustomOpenAPISchemaGenerator', you can tailor the Swagger document generation to meet specific needs, such as enhancing readability, formatting, or supporting additional features not directly offered by default.

2. Security Considerations: The security settings ("SECURITY_DEFINITIONS" are commented out. If security is important, consider defining appropriate mechanisms for accessing resources securely in accordance with your application's architecture.

3. Model Rendering: "DEFAULT_MODEL_RENDERING" set to "example" might be useful for generating models inline with example values. However, this setting does not affect rendering; it only affects the way examples are displayed alongside model schemas when viewing them through tools like Postman or cURL.

The overall structure looks clean and functional for integrating custom configurations into Django Rest Framework (DRF) using Swaggrator.

[shaohuzhang1]

The code is mostly correct, but there's one small issue that needs to be addressed:

+tags_dict = {

It seems like this line should not be preceded by a plus sign. The from statement already imports the necessary modules, so adding an additional '+' is unnecessary.

Here's the corrected version:

from drf_yasg.generators import OpenAPISchemaGenerator
from drf_yasg.inspectors import SwaggerAutoSchema

# Remove the plus sign before tags_dict
tags_dict = {

This change ensures clarity and avoids confusion with syntax characters in Python. Note that your changes look good otherwise!

[shaohuzhang1]

Your code appears to be correctly defined and should work without any immediate issues. However, here a few optimizations and additional checks you might want to consider:

1. Custom OpenAPI Schema Generator: Ensure that common.config.swagger_conf.CustomOpenAPISchemaGenerator is implemented properly. It's crucial that it extends openapi_spec_validator.generators.BaseGenerator and overrides methods like get_paths().

2. Default Model Rendering: If "DEFAULT_MODEL_RENDERING" is set to 'example', this means Swagger/OpenAPI will render examples of model instances. Consider how well these examples meet your needs for documentation clarity.

3. Security Definitions: Double-check the SECURITY_DEFINITIONS dictionary. Make sure all necessary authentication methods are supported if they're configured.

4. Error Handling: Since there's no error handling logic in the snippet provided, ensure that your application has robust error handling for production use cases.

Overall, your approach seems sound, but reviewing these aspects can help improve both functionality and maintainability.