refactor: move OpenApiParameter definitions to schema for better organization

[shaohuzhang1]

refactor: move OpenApiParameter definitions to schema for better organization --bug=1064802 --user=刘瑞斌 【接口文档】/admin/api/workspace/{workspace_id}/knowledge/{knowledge_id}/document/split 接口的参数传递方式错了 https://www.tapd.cn/62980211/s/1813972

[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-sigs/prow 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]

The given Python function appears to be setting up API parameters using Django Rest Framework (DRF). Here are some points of concern and recommendations:

1. Django vs FastAPI:

   • The example uses djangorestframework for defining parameters, but you're likely working with FastAPI if you see similar code structures. If this is indeed DRF, please note that DRF has its own way of handling query parameters.

2. Parameter Naming:

   • The parameter names (limit, patterns, with_filter) are consistent across both functions, which is good unless there are specific naming conventions in place.

3. Type Definitions:

   • All types are correctly defined, such as INT for integers and BOOL for booleans. Ensure consistency in the usage of these types.

4. Documentation and Descriptions:

   • Each parameter has a description provided in Swagger format within the operation.get_request() method. This is excellent practice for clarity and maintainability.

5. Location Parameters:

   • The location (location='query') is correct according to the requirements. However, ensure that other parameters also follow this pattern consistently if you have other methods like POST requests where different locations might be appropriate.

6. Binary File Handling:

   • The addition of 'file': {'type': 'string', 'format': 'binary'}
     in get_request() suggests handling files or binary data. Make sure this line fits into your design and does not conflict with existing logic.

7. Optimization Suggestions:

   • There doesn’t appear to be significant opportunities for optimization in the current implementation. Ensure that all fields are necessary and perform efficiently within their contexts.
   • Consider adding more thorough validation on certain inputs, particularly if they interact with sensitive operations.

Overall, the code looks well-structured and should work effectively once integrated into an API setup. Make sure to adjust it accordingly based on whether you’re using Django REST Framework or FastAPI.