An API request parameter visual modeling method, device, equipment and medium
Patent Information
- Application Number
- CN202610495145.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-15
- Publication Date
- 2026-08-11
AI Technical Summary
虽然部分工具支持从JSON Schema生成表单，或提供简单的表格式输入，但它们普遍缺乏对复杂嵌套结构（如对象数组、多层对象嵌套）的专门可视化建模能力
[0019]根据本申请的另一方面，提供了一种计算机程序产品，计算机程序产品包括计算机程序，该计算机程序被处理器执行时实现本申请任一实施例的API请求参数可视化建模方法。
Smart Images
Figure CN122547336A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of data visualization and intelligent interaction technology, and in particular to a method, apparatus, device and medium for visual modeling of API request parameters. Background Technology
[0002] In current software development practices, the definition and management of HTTP API request parameters mainly rely on the following technical solutions: a. Annotation-based approach: Developers use specific annotations in the backend code to describe the API's path, methods, parameters, etc. During the build process, the tool scans these annotations and automatically generates an OpenAPI specification document. The advantage of this method is that the API definition and implementation code are tightly coupled, making it easy to keep in sync. However, its disadvantage is that the parameter structure definition is plain text. For complex request bodies with multiple nested levels, developers need to manually write hierarchical POJO classes to represent them, lacking intuitive visual feedback. Furthermore, modifying the hierarchical relationship requires code refactoring, which is cumbersome. b. Independent API design and documentation tools: These tools provide graphical user interfaces (GUIs) to help developers design, debug, and document APIs. In these tools, developers can create key-value pair lists for API parameters such as Query and Headers. For the request body, a text editing area is usually provided, allowing users to directly write raw data in JSON, XML, or other formats. While some tools support generating forms from JSON Schema or provide simple tabular input, they generally lack specialized visual modeling capabilities for complex nested structures (such as arrays of objects or multi-level nested objects). Users still need to manually maintain hierarchy, parentheses, and commas in large blocks of text, which is prone to errors. Summary of the Invention
[0003] This application provides an API request parameter visualization modeling method, apparatus, device, and medium to achieve visualization and interactive modeling of request parameters of various structures, improving the convenience and operability of modeling, and enhancing the rigor and correctness of the parameter model through consistency constraints.
[0004] According to one aspect of this application, a method for visually modeling API request parameters is provided, the method comprising:
[0005] In the visual interface constructed by the unified parameter type view and switching module, a navigation component is established; wherein, the navigation component contains tabs corresponding to multiple preset request parameter types, including Body, Query, Headers, and Path types;
[0006] If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter editor for the corresponding preset request parameter type will be asynchronously loaded and displayed in the parameter configuration area under the corresponding tab.
[0007] If a user is detected to be performing an editing operation on a preset request parameter type, the parameter editor will respond and execute the editing operation, and trigger and apply the consistency constraint engine. Based on the consistency constraint engine, the request parameter data model formed by the user's editing operation will be checked for consistency.
[0008] If the consistency check passes, the request parameter data model generated by the user's editing operation is used as the final API request parameter model.
[0009] According to one aspect of this application, an API request parameter visualization modeling apparatus is provided, the apparatus comprising:
[0010] The navigation component creation module is used to create navigation components in the visual interface constructed by the unified parameter type view and the switching module; wherein, the navigation component contains multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path types;
[0011] The parameter editor loading module is used to asynchronously load and display the parameter editor for the corresponding preset request parameter type in the parameter configuration area under the corresponding tab if the user triggers an editing operation on the preset request parameter type through the navigation component.
[0012] The consistency verification module is used to respond to and execute the editing operation through the parameter editor if it detects that the user has performed an editing operation on a preset request parameter type, and to trigger and apply the consistency constraint engine to perform consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine.
[0013] The request parameter model determination module is used to determine the final API request parameter model based on the request parameter data model formed by the user's editing operation, provided that the consistency check passes.
[0014] According to another aspect of this application, an electronic device is provided, the electronic device comprising:
[0015] At least one processor; and,
[0016] A memory that is communicatively connected to at least one processor; wherein,
[0017] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor can execute the API request parameter visualization modeling method of any embodiment of this application.
[0018] According to another aspect of this application, a computer-readable storage medium is provided, which stores computer instructions for causing a processor to execute and implement the API request parameter visualization modeling method of any embodiment of this application.
[0019] According to another aspect of this application, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the API request parameter visualization modeling method of any embodiment of this application.
[0020] The technical solution of this application embodiment establishes a navigation component in the visual interface constructed by the unified parameter type view and switching module. The navigation component includes multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path. If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter configuration area under the corresponding tab asynchronously loads and displays the parameter editor for that preset request parameter type. If the user's editing operation on a preset request parameter type is detected, the parameter editor responds and executes the editing operation, triggering and applying a consistency constraint engine. Based on the consistency constraint engine, the request parameter data model formed by the user's editing operation is validated for consistency. If the consistency validation passes, the request parameter data model formed by the user's editing operation is used as the final API request parameter model. This solution provides a unified graphical user interface that distinguishes and manages four types of request parameters (Body, Query, Headers, and Path) through tabs, abstracting API request parameters into a unified data model that can be visualized and manipulated, thus eliminating the tedious and error-prone nature of manually writing JSON. By leveraging a consistency constraint engine that operates in real-time in the background, a series of rules are automatically enforced when the user performs editing operations. This ensures that errors in the parametric model are detected and corrected immediately, improving the rigor and correctness of the established model. Combining visual modeling with real-time constraints significantly reduces the complexity and error rate of API parameter definitions, providing a highly consistent and reliable data structure foundation for subsequent interface integration, data mapping, and automated testing.
[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description
[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0023] Figure 1 A flowchart illustrating an API request parameter visualization modeling method provided in this application embodiment;
[0024] Figure 2 A flowchart illustrating a method for visually modeling API request parameters, provided in another embodiment of this application;
[0025] Figure 3 A flowchart illustrating a method for visually modeling API request parameters, provided in yet another embodiment of this application;
[0026] Figure 4 A flowchart for verifying the consistency of modified parameter types is provided in another embodiment of this application;
[0027] Figure 5 A flowchart for verifying the consistency of the modified interface path is provided in another embodiment of this application;
[0028] Figure 6 A complete architecture diagram of a visual editing method for API request parameters provided in this application embodiment;
[0029] Figure 7 A schematic diagram of the structure of an API request parameter visualization modeling device provided in an embodiment of this application;
[0030] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0031] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.
[0032] It should be noted that the terms "first," "second," "third," "fourth," "actual," "preset," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.
[0033] The acquisition, storage, use, and processing of data in this application comply with relevant national laws and regulations. The acquired data is obtained with authorization and will not be disclosed without permission, used for illegal purposes, purposes detrimental to the interests of others, or for personalized analysis or product promotion. It should be noted that certain software, components, models, and other existing industry solutions may be mentioned in the embodiments of this application. These should be considered exemplary and intended only to illustrate the feasibility of implementing the technical solution of this application, but do not imply that the applicant has already used or necessarily used the relevant content of such solutions.
[0034] Figure 1 This flowchart illustrates an API request parameter visualization modeling method provided in this application embodiment. This embodiment is applicable to situations where a target layout template is dynamically and adaptively selected and displayed on a target screen. The method can be executed by an API request parameter visualization modeling device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method includes:
[0035] S110. In the visual interface constructed by the unified parameter type view and switching module, a navigation component is established; wherein, the navigation component contains multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path types.
[0036] The Unified Parameter Type View and Switching Module is a functional module deployed in electronic devices. It is a top-level interaction framework that has the ability to build a visual interface and provide users with interactive functions. The Unified Parameter Type View and Switching Module is the entry point for user interaction, providing a clear and unified view to organize different types of API request parameters. It can call other modules according to the user's selection and realize the editing of parameter models.
[0037] For example, in the visual interface built with the unified parameter type view and switching module, a navigation component is created. Specifically, this is implemented by creating a Tab navigation component containing four fixed tabs: "Body," "Query," "Headers," and "Path." When a user clicks a tab, they are redirected to the corresponding editing interface. This solution unifies the four parameters—Body, Query, Headers, and Path—within a single editor framework, organized through tabs. This not only provides a centralized management entry point, avoiding the cumbersome switching between different tools or interfaces, but also establishes a unified cognitive model, allowing developers to define all parameters in one place.
[0038] S120. If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter editor for the corresponding preset request parameter type will be asynchronously loaded and displayed in the parameter configuration area under the corresponding tab.
[0039] For example, if a user triggers an editing operation on a preset request parameter type through a navigation component, the parameter editor for that preset request parameter type can be asynchronously loaded and displayed in the parameter configuration area of the corresponding tab. This editor is used to construct the corresponding parameter model based on the user's editing operation. For instance, clicking "Body" loads and displays the hierarchical parameter editor for "Body," while clicking "Query" loads and displays the key-value pair list parameter editor for "Query." This tab-based interface differentiation management ensures state preservation and context isolation. When a user configures a complex nested structure under the "Body" tab, switches to the "Query" tab, and then switches back to the "Body" tab, all previously configured Body parameters and their hierarchical relationships can be completely and accurately restored and displayed. In other words, the editing results under each tab do not affect each other and can be operated independently. This achieves logical decoupling of the configuration process for different parameters while maintaining a high degree of UI consistency and a smooth switching experience, avoiding cognitive confusion when jumping between multiple independent windows or pages.
[0040] S130. If it is detected that the user performs an editing operation on a preset request parameter type, the parameter editor responds and executes the editing operation, and triggers and applies the consistency constraint engine, and performs consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine.
[0041] For example, if a user's edit operation on the corresponding interface under a tab is detected, the parameter editor will respond and execute the corresponding edit operation to set and build the parameter model.
[0042] In this embodiment, a consistency constraint engine is pre-built. When a user performs an editing operation, the parameter editor responds and executes the editing operation while simultaneously triggering and applying the consistency constraint engine. Based on the consistency constraint engine, the request parameter data model formed by the user's editing operation is subjected to consistency verification. This verification checks whether the request parameters meet pre-set requirements. The pre-set requirements are based on the design principles of the request parameters, namely, the standardization and accuracy requirements of the request parameters. The consistency constraint engine can immediately provide feedback when a user performs any operation that might violate the rules, such as modifying the URL path or changing the parameter data type, and can automatically perform repair actions, such as removing child nodes under atomic types, ensuring the inherent rigor of the API definition.
[0043] S140. If the consistency check passes, the request parameter data model formed by the user's editing operation shall be used as the final API request parameter model.
[0044] For example, if the consistency constraint engine passes the verification, it indicates that the user-edited request parameters are problem-free and meet the internal correlation requirements of the request parameters. The request parameter data model formed by the user's editing operation can then be used as the final API request parameter model. By triggering and applying the consistency constraint engine in real time, the "real-time" and "automatic repair" characteristics are achieved based on the real-time, rule-based automatic consistency verification and correction mechanism embedded in the editor's interaction flow, fundamentally preventing the generation of non-standard request parameter configurations.
[0045] The technical solution of this application embodiment establishes a navigation component in the visual interface constructed by the unified parameter type view and switching module. The navigation component includes multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path. If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter configuration area under the corresponding tab asynchronously loads and displays the parameter editor for that preset request parameter type. If the user's editing operation on a preset request parameter type is detected, the parameter editor responds and executes the editing operation, triggering and applying a consistency constraint engine. Based on the consistency constraint engine, the request parameter data model formed by the user's editing operation is validated for consistency. If the consistency validation passes, the request parameter data model formed by the user's editing operation is used as the final API request parameter model. This solution provides a unified graphical user interface that distinguishes and manages four types of request parameters (Body, Query, Headers, and Path) through tabs, abstracting API request parameters into a unified data model that can be visualized and manipulated, thus eliminating the tedious and error-prone nature of manually writing JSON. By leveraging a consistency constraint engine that operates in real-time in the background, a series of rules are automatically enforced when the user performs editing operations. This ensures that errors in the parametric model are detected and corrected immediately, improving the rigor and correctness of the established model. Combining visual modeling with real-time constraints significantly reduces the complexity and error rate of API parameter definitions, providing a highly consistent and reliable data structure foundation for subsequent interface integration, data mapping, and automated testing.
[0046] Figure 2 This is a flowchart illustrating a method for visualizing and modeling API request parameters, provided as another embodiment of this application. This embodiment is an optimization based on the above embodiment; solutions not described in detail in this embodiment are found in the above embodiment. Figure 2 As shown, the method in this embodiment of the application specifically includes the following steps:
[0047] S210. A tree-like or indented list-style structure editor based on page elements, serving as a parameter editor for the Body type.
[0048] For example, for Body type request parameters, since these parameters are generally hierarchically nested and have a complex structure, a tree-like or indented list-style structure editor can be created based on page elements to serve as the parameter editor for the Body type. The tree-like structure editor provides the functionality to edit the tree structure, meaning that individual nodes can be deleted and new nodes can be added. The indented list style uses different indentation levels to represent the nesting relationship between request parameters; request parameters with the same indentation level are at the same level.
[0049] S220. Create a list-style editor as a parameter editor for Query, Headers, and Path types.
[0050] For example, for request parameters of the Query, Headers, and Path types, since these types of request parameters are relatively simple and do not have nested relationships, they are essentially flat collections of key-value pairs. Therefore, a list-style editor can be created as a parameter editor for these types, thereby providing a unified and concise list-style editor.
[0051] S230. In the visual interface constructed by the unified parameter type view and switching module, associate each parameter editor with its corresponding tab to establish the navigation component.
[0052] For example, in the visual interface constructed with the unified parameter type view and switching module, each parameter editor is associated with its corresponding tab to create a navigation component. Specifically, the parameter editor for the Body type is associated with its corresponding tab, the parameter editor for the Query type is associated with its corresponding tab, and so on for other types. When parameter editors are associated with tabs, clicking a tab will switch to the interface corresponding to that tab, and the corresponding parameter editor will be loaded and displayed on that interface for easy editing.
[0053] S240. If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter editor for the corresponding preset request parameter type will be asynchronously loaded and displayed in the parameter configuration area under the corresponding tab.
[0054] In this embodiment, if a user triggers an editing operation on a preset request parameter type through a navigation component, a parameter editor for the corresponding preset request parameter type is asynchronously loaded and displayed in the parameter configuration area under the corresponding tab, including:
[0055] If the user clicks the tab corresponding to the Body type, the parameter editor corresponding to the Body type will be loaded and displayed in the parameter configuration area under the tab. The first editing control will be loaded in each row of the structure presented by the parameter editor. The first editing control includes an input box, a data type selection box, a required field check box, a remarks input box, an add button, and a delete button.
[0056] If the user clicks on other types of tabs, a parameter editor corresponding to the preset request parameter type will be loaded in the parameter configuration area under the tab. A second editing control will be loaded in each column of the list presented by the parameter editor, and a third editing control will be loaded at the bottom of the list. The second editing control includes a parameter name input box, a required status selection box, a parameter instance input box, and a remarks input box. The third editing control includes an add parameter button and a delete parameter button.
[0057] In this embodiment, if a user clicks the tab corresponding to the Body type, the parameter editor corresponding to the Body type is loaded and displayed in the parameter configuration area under the tab. Based on the parameter characteristics of the Body type request parameters, a corresponding first editing control can be loaded in each row of the architecture presented by the parameter editor, making it convenient for the user to trigger the first editing control to edit the request parameters. The first editing control includes an input box, a data type selection box, a required field checkbox, a remarks input box, an add button, and a delete button. The data type selection box supports the selection of parameter types such as string, number, boolean, object, and array. When the data type of a request parameter is set to "object" or "array", an "Add Subset" icon button will automatically appear next to that row. The user can click this button to insert a new sub-parameter row below it, thereby building a hierarchical relationship. The user can repeat this operation to create a nested structure of arbitrary depth. At the same time, each row also provides a "Delete" button. Deleting the parent node will delete all its child nodes in conjunction with the deletion, and a secondary confirmation box will pop up to prevent accidental operation. The above solution greatly reduces the mental burden by visualizing the abstract JSON tree structure into a sequence of UI components that users can directly manipulate.
[0058] In this embodiment, if the user clicks on another type of tab, a parameter editor corresponding to the preset request parameter type is loaded in the parameter configuration area under the tab. A second editing control is loaded in each column of the list presented by the parameter editor, and a third editing control is loaded at the bottom of the list. The second editing control includes a parameter name input box, a required status selection box, a parameter instance input box, and a remarks input box. The third editing control includes an add parameter button and a delete parameter button, all set according to the editing requirements of the request parameters. Specifically, the interface consists of a table that can dynamically add and delete rows. Each row represents a parameter and includes the following columns: parameter name (input box), required status (selection box, selectable as "required" or "not required"), parameter instance (input box), and remarks (input box). The user adds a row by clicking the "Add Parameter" button at the bottom of the table. Each row has a "Delete" icon button at the end; clicking it directly deletes the row without secondary confirmation, making the operation quick and easy. By providing differentiated but consistent editors for parameter types of varying complexity, a good balance is achieved between professionalism and ease of use.
[0059] In this embodiment of the application, if a user clicks the tab corresponding to the Body type and the parameter editor responds and executes the editing operation, it includes:
[0060] If a user triggers the add button for the target row, a new sub-parameter row is inserted below the target row, creating a hierarchical relationship where the target row is nested with the sub-parameter row.
[0061] If a user triggers the delete button for the target row, the target row and all its nested sub-parameter rows will be deleted.
[0062] For example, in the parameter editor corresponding to the Body type, when the data type of a request parameter is set to "object" or "array", an "Add Subset" icon button will automatically appear next to the target line. Clicking this button will insert a new sub-parameter line below it, thus building a hierarchical relationship. Users can repeat this operation to create nested structures of arbitrary depth. Simultaneously, each line also provides a "Delete" button; deleting the parent node will delete all its child nodes, and a secondary confirmation dialog will pop up to prevent accidental operations. This solution transforms the abstract data structure building process into intuitive graphical operations by providing a visual, interactive hierarchical modeler. Users can complete the construction and modification of complex nested structures by clicking buttons such as "Add Subset" and "Delete," without needing to worry about JSON syntax details. This greatly reduces the mental burden on developers, shortening what would have been a time-consuming and error-prone text editing task to a second-level, error-free UI interaction, thereby significantly improving the efficiency and first-time accuracy of API definition.
[0063] In this embodiment of the application, responding to and executing the editing operation through the parameter editor includes:
[0064] For nodes of type object or array, if the user triggers the expand or collapse button, the preset rows will be merged and hidden or the merged and hidden preset rows will be expanded and displayed.
[0065] For example, for nodes of type object or array, an "expand / collapse" function is also provided, which makes it easier for users to focus on the part of interest in a complex structure.
[0066] S250. If it is detected that the user performs an editing operation on a preset request parameter type, the parameter editor responds and executes the editing operation, and triggers and applies the consistency constraint engine, and performs consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine.
[0067] S260. If the consistency check passes, the request parameter data model formed by the user's editing operation shall be used as the final API request parameter model.
[0068] The solution in this application embodiment establishes a tree-like or indented list-style structure editor based on page elements, serving as the parameter editor for the Body type; it also establishes a list-style editor as the parameter editor for Query, Headers, and Path types; and it associates each parameter editor with its corresponding tab in a visual interface constructed from a unified parameter type view and switching module, thus establishing the navigation component. This method unifies all parameter types (Body, Query, Header, Path) into a visual, interactive tree-like hierarchical structure. Simultaneously, although the view is unified, they are still managed separately within the model, retaining their respective domain-specific attributes (such as the hierarchical structure of Body and the key-value pair format of Query). This greatly simplifies the parameter cognitive model of complex APIs and reduces the cognitive load on users. The complex, infinitely nestable Body parameters (JSON) are modeled and embedded in a unified parameter tree with an intuitive parent-child hierarchical relationship, supporting complex operations such as hierarchical adjustment and type change through simple clicks and drags.
[0069] Figure 3 This is a flowchart illustrating a method for visually modeling API request parameters, provided as another embodiment of this application. This embodiment is an optimization based on the above embodiments; solutions not described in detail in this embodiment are found in the above embodiments. Figure 3 As shown, the method in this embodiment of the application specifically includes the following steps:
[0070] S310. In the visual interface constructed by the unified parameter type view and switching module, a navigation component is established; wherein, the navigation component contains multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path types.
[0071] S320. If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter editor for the corresponding preset request parameter type will be asynchronously loaded and displayed in the parameter configuration area under the corresponding tab.
[0072] S330. If it is detected that the user performs an editing operation on a preset request parameter type, then the parameter editor responds and executes the editing operation.
[0073] S340. Invoke the consistency constraint engine and obtain the user-edited request parameter data from the request parameter data model based on the consistency constraint engine.
[0074] For example, after the parameter editor responds and performs an editing operation, the consistency constraint engine can be invoked to retrieve the user-edited request parameter data from the request parameter data model. Specifically, this means retrieving the request parameter data from the parameter editors of the corresponding interfaces under the tabs triggered by the user, including parameters from rows added, deleted, and edited by the user.
[0075] S350. The consistency of the request parameter data is verified by using the pre-set constraint rules in the consistency constraint engine.
[0076] For example, threshold constraint rules in a consistency constraint engine can be used to perform consistency checks on request parameter data. These constraint rules are set according to the requirements of the request parameters. The consistency constraint engine can then verify the user-edited request parameter data based on these constraint rules to determine whether the user-edited request parameter data is compliant.
[0077] In this embodiment of the application, the consistency of the request parameter data is verified using the pre-defined constraint rules in the consistency constraint engine, including:
[0078] The request parameter data is subject to a unique naming constraint at the same level. If at least two identical parameter names exist in the same parent node or in the same parameter type list, an error will be prompted and the current editing operation will be blocked.
[0079] If the user performs a change from the first parameter type to the second parameter type, then data type-driven structural integrity constraints are applied to the sub-parameters under the parameter of the first parameter type, the sub-parameters are cleared, and a prompt is issued to the user.
[0080] Listen to the interface path input box, obtain the variable name in the interface path, apply strong association constraint between the path parameter and the address template to the variable name, and verify whether the parameter name defined in the path parameter list is consistent with the variable name; if the user deletes the variable name, the corresponding parameter in the parameter list will be indicated as redundant; if the user adds the variable name, the corresponding parameter will be prompted to be added in the parameter list.
[0081] For example, during consistency verification via the consistency constraint engine, the process includes applying a unique naming constraint to request parameter data at the same level. If at least two identical parameter names exist within the same parent node or within the same parameter type list, an error is displayed and the editing operation is blocked. Specifically, under the same parent node (for the Body parameter) or within the same parameter type list (for at least one of Query, Headers, and Path), all parameter names must be unique. When a user enters a duplicate name, the system immediately displays an error and blocks the modification.
[0082] If the user changes the parameter type from the first parameter type to the second parameter type, then data type-driven structural integrity constraints are applied to the sub-parameters under the parameter of the first parameter type, the sub-parameters are cleared, and a prompt is issued to the user. Specifically, for example... Figure 4 As shown, when a user attempts to change a parameter with a data type of "object" or "array" to an atomic type such as "string" or "number", the consistency constraint engine determines that its original sub-parameters become meaningless. Therefore, the consistency constraint engine triggers an action to automatically clear all sub-parameter definitions under its name and may prompt the user to confirm this operation. This ensures that the data model will not have logical contradictions such as "a string type variable with multiple sub-attributes".
[0083] The system listens for the API path input field, retrieves variable names from the API path, applies strong association constraints between the variable names and the path parameters and address templates, and verifies whether the parameter names defined in the path parameter list match the variable names. If the user deletes a variable name, the system indicates that the corresponding parameter is redundant in the parameter list; if the user adds a variable name, the system prompts the user to add the corresponding parameter. Figure 5As shown, specifically, the consistency constraint engine continuously monitors the "Interface Path" input box in the API master information (e.g., / api / users / {userId} / posts / {postId}). It uses regular expressions to parse all variable names (userId, postId) enclosed in curly braces {} in the path in real time. The consistency constraint engine verifies whether the parameter names defined in the "Path" parameter list are completely consistent with the parsed variable names. If the user deletes {postId} in the path, the corresponding postId line in the Path parameter list will be automatically highlighted as redundant; conversely, if {orderId} is added, the consistency constraint engine will prompt the user to add a parameter named orderId to the Path parameter list. This strong association mechanism completely eliminates the problem of mismatch between path and parameter definitions. By directly binding the parsing of the URL template with the definition of the Path parameter, dynamic, bidirectional synchronization between the two is achieved. Modifying the URL will automatically prompt for adding or deleting Path parameters, and vice versa.
[0084] S360. If the consistency check passes, the request parameter data model formed by the user's editing operation shall be used as the final API request parameter model.
[0085] In this embodiment, a consistency constraint engine is invoked to obtain the user-edited request parameter data from the request parameter data model. The consistency constraint engine then uses pre-defined constraint rules to perform consistency verification on the request parameter data. Real-time consistency constraints ensure the inherent rigor of the API definition. The consistency constraint engine in this solution performs real-time verification at every step of the user's editing process, a fundamental improvement over the traditional "edit first, verify later" approach. For example, the "unique naming at the same level" constraint avoids logical errors caused by parameter name confusion later; the "clear sub-parameters upon type change" rule ensures the logical consistency of the data model, preventing invalid structures such as "a string node has child nodes"; and in particular, the "strong association between Path parameters and URL templates" constraint completely eliminates errors caused by manual maintenance of inconsistencies, preemptively eliminating potential runtime errors during the design phase.
[0086] This application provides a complete architecture for visually editing API request parameters, such as... Figure 6As shown, the top-level "Unified Parameter Type View and Switching Module" serves as the entry point for user interaction. Based on the user's selection, it invokes either the "Hierarchical Body Parameter Visualization Modeling Module" or the "Flattened Key-Value Pair Parameter Configuration Module." All operations of these two UI modules modify the underlying "Unified API Parameter Data Model." Any change to the data model triggers verification by the "Consistency Constraint Engine." The engine checks or modifies the data model according to built-in rules and feeds the results back to the UI module, thus forming a closed-loop, real-time, and controlled editing process.
[0087] Figure 7 This is a schematic diagram of an API request parameter visualization modeling device provided in an embodiment of this application. This device can execute the API request parameter visualization modeling method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the method execution. Figure 7 As shown, the device includes:
[0088] The navigation component creation module 410 is used to create a navigation component in the visual interface constructed by the unified parameter type view and the switching module; wherein, the navigation component includes multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path types;
[0089] The parameter editor loading module 420 is used to asynchronously load and display the parameter editor for the corresponding preset request parameter type in the parameter configuration area under the corresponding tab if the user triggers an editing operation on the preset request parameter type through the navigation component.
[0090] The consistency verification module 430 is used to respond to and execute the editing operation through the parameter editor if it detects that the user has performed an editing operation on a preset request parameter type, and to trigger and apply the consistency constraint engine to perform consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine.
[0091] The request parameter model determination module 440 is used to determine the final API request parameter model based on the request parameter data model formed by the user's editing operation, provided that the consistency check passes.
[0092] In this embodiment, the navigation component creation module 410 creates a navigation component in the visual interface constructed by the unified parameter type view and the switching module, including:
[0093] A tree-like or indented list-style structure editor is created based on page elements, serving as a parameter editor for the Body type.
[0094] Create a list-style editor to serve as a parameter editor for Query, Headers, and Path types;
[0095] In the visual interface constructed by the unified parameter type view and switching module, each parameter editor is associated with its corresponding tab to establish the navigation component.
[0096] In this embodiment, if a user triggers an editing operation on a preset request parameter type through a navigation component, the parameter editor loading module 420 asynchronously loads and displays the parameter editor for the corresponding preset request parameter type in the parameter configuration area under the corresponding tab, including:
[0097] If the user clicks the tab corresponding to the Body type, the parameter editor corresponding to the Body type will be loaded and displayed in the parameter configuration area under the tab. The first editing control will be loaded in each row of the structure presented by the parameter editor. The first editing control includes an input box, a data type selection box, a required field check box, a remarks input box, an add button, and a delete button.
[0098] If the user clicks on other types of tabs, a parameter editor corresponding to the preset request parameter type will be loaded in the parameter configuration area under the tab. A second editing control will be loaded in each column of the list presented by the parameter editor, and a third editing control will be loaded at the bottom of the list. The second editing control includes a parameter name input box, a required status selection box, a parameter instance input box, and a remarks input box. The third editing control includes an add parameter button and a delete parameter button.
[0099] In this embodiment of the application, if the user clicks the tab corresponding to the Body type, the consistency verification module 430 responds through the parameter editor and executes the editing operation, including:
[0100] If a user triggers the add button for the target row, a new sub-parameter row is inserted below the target row, creating a hierarchical relationship where the target row is nested with the sub-parameter row.
[0101] If a user triggers the delete button for the target row, the target row and all its nested sub-parameter rows will be deleted.
[0102] In this embodiment of the application, the consistency verification module 430 responds to and executes the editing operation through the parameter editor, including:
[0103] For nodes of type object or array, if the user triggers the expand or collapse button, the preset rows will be merged and hidden or the merged and hidden preset rows will be expanded and displayed.
[0104] In this embodiment, the consistency verification module 430 triggers and applies the consistency constraint engine, and performs consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine, including:
[0105] Invoke the consistency constraint engine, and obtain the user-edited request parameter data from the request parameter data model based on the consistency constraint engine;
[0106] The consistency of the request parameter data is verified using the pre-defined constraint rules in the consistency constraint engine.
[0107] In this embodiment of the application, the consistency verification module 430 uses the preset constraint rules in the consistency constraint engine to perform consistency verification on the request parameter data, including:
[0108] The request parameter data is subject to a unique naming constraint at the same level. If at least two identical parameter names exist in the same parent node or in the same parameter type list, an error will be prompted and the current editing operation will be blocked.
[0109] If the user performs a change from the first parameter type to the second parameter type, then data type-driven structural integrity constraints are applied to the sub-parameters under the parameter of the first parameter type, the sub-parameters are cleared, and a prompt is issued to the user.
[0110] Listen to the interface path input box, obtain the variable name in the interface path, apply strong association constraint between the path parameter and the address template to the variable name, and verify whether the parameter name defined in the path parameter list is consistent with the variable name; if the user deletes the variable name, the corresponding parameter in the parameter list will be indicated as redundant; if the user adds the variable name, the corresponding parameter will be prompted to be added in the parameter list.
[0111] The API request parameter visualization modeling device provided in this application embodiment can execute the API request parameter visualization modeling method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects of the execution method.
[0112] Figure 8A schematic diagram of an electronic device 10, which can be used to implement embodiments of this application, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital processors, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.
[0113] like Figure 8 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.
[0114] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.
[0115] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as the API request parameter visualization modeling method.
[0116] In some embodiments, the API request parameter visualization modeling method can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the API request parameter visualization modeling method described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the API request parameter visualization modeling method by any other suitable means (e.g., by means of firmware).
[0117] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.
[0118] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to the processor of a general-purpose computer, a special-purpose computer, or other programmable API request parameter visualization modeling device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0119] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0120] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).
[0121] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.
[0122] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.
[0123] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the API request parameter visualization modeling method provided in any embodiment of this application.
[0124] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages or a combination thereof. Programming languages include object-oriented programming languages such as Java, Smalltalk, and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).
[0125] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired information of the technical solution of this application can be achieved, and this is not limited herein.
[0126] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method for visually modeling API request parameters, characterized in that, The method includes: In the visual interface constructed by the unified parameter type view and switching module, a navigation component is established; wherein, the navigation component contains tabs corresponding to multiple preset request parameter types, including Body, Query, Headers, and Path types; If a user triggers an editing operation on a preset request parameter type through the navigation component, the parameter editor for the corresponding preset request parameter type will be asynchronously loaded and displayed in the parameter configuration area under the corresponding tab. If a user is detected to be performing an editing operation on a preset request parameter type, the parameter editor will respond and execute the editing operation, and trigger and apply the consistency constraint engine. Based on the consistency constraint engine, the request parameter data model formed by the user's editing operation will be checked for consistency. If the consistency check passes, the request parameter data model generated by the user's editing operation is used as the final API request parameter model.
2. The method according to claim 1, characterized in that, Within the visual interface built using the unified parameter type view and switching module, a navigation component is created, including: A tree-like or indented list-style structure editor is created based on page elements, serving as a parameter editor for the Body type. Create a list-style editor to serve as a parameter editor for Query, Headers, and Path types; In the visual interface constructed by the unified parameter type view and switching module, each parameter editor is associated with its corresponding tab to establish the navigation component.
3. The method according to claim 1 or 2, characterized in that, If a user triggers an editing operation on a preset request parameter type through a navigation component, the parameter editor for the corresponding preset request parameter type will be asynchronously loaded and displayed in the parameter configuration area under the corresponding tab, including: If the user clicks the tab corresponding to the Body type, the parameter editor corresponding to the Body type will be loaded and displayed in the parameter configuration area under the tab. The first editing control will be loaded in each row of the structure presented by the parameter editor. The first editing control includes an input box, a data type selection box, a required field check box, a remarks input box, an add button, and a delete button. If the user clicks on other types of tabs, a parameter editor corresponding to the preset request parameter type will be loaded in the parameter configuration area under the tab. A second editing control will be loaded in each column of the list presented by the parameter editor, and a third editing control will be loaded at the bottom of the list. The second editing control includes a parameter name input box, a required status selection box, a parameter instance input box, and a remarks input box. The third editing control includes an add parameter button and a delete parameter button.
4. The method according to claim 3, characterized in that, If the user clicks the tab corresponding to the Body type, the parameter editor will respond and execute the editing operation, including: If a user triggers the add button for the target row, a new sub-parameter row is inserted below the target row, creating a hierarchical relationship where the target row is nested with the sub-parameter row. If a user triggers the delete button for the target row, the target row and all its nested sub-parameter rows will be deleted.
5. The method according to claim 3, characterized in that, The parameter editor responds to and executes the editing operation, including: For nodes of type object or array, if the user triggers the expand or collapse button, the preset rows will be merged and hidden or the merged and hidden preset rows will be expanded and displayed.
6. The method according to claim 1, characterized in that, Triggering and applying the consistency constraint engine, and performing consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine, including: Invoke the consistency constraint engine, and obtain the user-edited request parameter data from the request parameter data model based on the consistency constraint engine; The consistency of the request parameter data is verified using the pre-defined constraint rules in the consistency constraint engine.
7. The method according to claim 6, characterized in that, The consistency of the request parameter data is verified using the pre-defined constraint rules in the consistency constraint engine, including: The request parameter data is subject to a unique naming constraint at the same level. If at least two identical parameter names exist in the same parent node or in the same parameter type list, an error will be prompted and the current editing operation will be blocked. If the user performs a change from the first parameter type to the second parameter type, then data type-driven structural integrity constraints are applied to the sub-parameters under the parameter of the first parameter type, the sub-parameters are cleared, and a prompt is issued to the user. Listen to the interface path input box, obtain the variable name in the interface path, apply strong association constraint between the path parameter and the address template to the variable name, and verify whether the parameter name defined in the path parameter list is consistent with the variable name; if the user deletes the variable name, the corresponding parameter in the parameter list will be indicated as redundant; if the user adds the variable name, the corresponding parameter will be prompted to be added in the parameter list.
8. An API request parameter visualization modeling device, characterized in that, The API request parameter visualization modeling device includes: The navigation component creation module is used to create navigation components in the visual interface constructed by the unified parameter type view and the switching module; wherein, the navigation component contains multiple tabs corresponding to preset request parameter types, including Body, Query, Headers, and Path types; The parameter editor loading module is used to asynchronously load and display the parameter editor for the corresponding preset request parameter type in the parameter configuration area under the corresponding tab if the user triggers an editing operation on the preset request parameter type through the navigation component. The consistency verification module is used to respond to and execute the editing operation through the parameter editor if it detects that the user has performed an editing operation on a preset request parameter type, and to trigger and apply the consistency constraint engine to perform consistency verification on the request parameter data model formed by the user's editing operation based on the consistency constraint engine. The request parameter model determination module is used to determine the final API request parameter model based on the request parameter data model formed by the user's editing operation, provided that the consistency check passes.
9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the API request parameter visualization modeling method according to any one of claims 1-7.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the API request parameter visualization modeling method according to any one of claims 1-7.