A method and system for API configuration option granularization

Abstract

The application relates to the technical field of computer data processing, and in particular to an API configuration option granulation extension method and system. The method comprises the following steps: obtaining a target customer instruction carrying configuration change information, performing field matching on the target customer instruction and sample configuration information in an API database; if the matching is successful, extracting an effective change field and switching the setting state of initial configuration information; if the matching fails, matching the instruction with sample function information, generating an independent configuration option after determining a second matching field, and synchronously adding the independent configuration option to the sample configuration information and the initial configuration information, and setting the independent configuration option to an enabled state. The application can realize automatic change and modular expansion of API platform configuration, improve the intelligence and flexibility of the configuration process, and reduce the customized development cost.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method and system for granular extension of API configuration options. Background Technology

[0002] Application Programming Interface (API) platforms, as crucial hubs connecting different software systems, play a central role in modern software development and integration. With increasingly complex business scenarios, API platforms need to support diverse protocol access and refined functional configurations to meet the differentiated needs of various customer groups. In existing technical solutions, API platform configuration management typically relies on predefined fixed templates or manual operations. When a customer requests a configuration change, technical personnel need to receive the instruction through the client and retrieve the corresponding configuration information from the backend database. They then identify the intention to change by comparing the customer's instruction with existing configuration fields. If the instruction matches an existing configuration item, its status is directly modified; if the instruction involves new functional requirements, the platform's function library needs to be further matched to determine the new functional module, and new configuration options are generated in the sample configuration and the customer's initial configuration, ultimately completing the status setting and activation.

[0003] However, in the face of massive and highly personalized customer demands, existing configuration processing methods often struggle to achieve truly granular management. When customer commands cannot accurately match preset standardized fields or function descriptions, the system lacks an effective automated response mechanism, forcing many customized requirements to rely on manual intervention for code-level modifications or tedious manual configuration. This processing mode not only has long response cycles and high maintenance costs, but is also prone to configuration inconsistencies or version chaos due to human error, making it difficult to support the flexible expansion and stable operation of the API platform in high-concurrency, rapid-iteration environments. Summary of the Invention

[0004] This application provides a method and system for granular extension of API configuration options to solve the above-mentioned problems.

[0005] Firstly, this application provides a method for granular extension of API configuration options, the method comprising: S1. Obtain the target customer instruction sent by the API client application server, wherein the target customer instruction carries configuration change information; S2. Obtain the sample configuration information stored in the API database, and perform field matching between the target customer instruction and the sample configuration information; S3. When the target customer instruction and the sample configuration information have a field match, determine the first matching field, extract the target change field corresponding to the first matching field from the target customer instruction, match the target change field with the sample change field stored in the API database, and determine the successfully matched target change field as a valid change field. S4. Obtain the initial configuration information stored in the API database that corresponds to the first matching field, and switch the setting status of the corresponding configuration option in the initial configuration information between the enabled state and the disabled state according to the valid change field. S5. When there is no field match between the target customer instruction and the sample configuration information, obtain the sample function information stored in the API database, perform field matching between the target customer instruction and the sample function information, and determine the second matching field when there is a field match. S6. Generate independent configuration options based on the second matching field, add the independent configuration options to the sample configuration information and the initial configuration information respectively, and set the newly added independent configuration options in the initial configuration information to the enabled state.

[0006] Optionally, the process of obtaining the target customer's instruction includes: Establish a communication connection between the API client application server and the client client; The client receives the selection operation of the customer for the configuration tag through the client service terminal, and generates the target customer instruction carrying the configuration change information based on the selected configuration tag. The client service terminal sends the target customer instruction to the API client application server to trigger API configuration processing for the corresponding customer.

[0007] Optionally, the step of matching the target customer instruction with the sample configuration information includes: Read pre-stored sample configuration information from the API database. The sample configuration information includes configuration fields corresponding to existing configuration options in the API platform. The configuration change information carried by the target customer instruction is matched with the configuration fields one by one; When there is a field in the configuration change information that matches the configuration field, the matching field is determined as the first matching field, and the existing configuration option pointed to by the target customer instruction is determined based on the first matching field. Extract the target change field from the target customer instruction to indicate the change in the setting status of the existing configuration options.

[0008] Optionally, the process for determining the valid change field includes: Read the pre-stored sample change field from the API database. The sample change field is used to characterize the setting status change content corresponding to the configuration option. The target change fields extracted from the target customer's instruction are matched with the sample change fields. When the target change field matches the sample change field, the matching target change field is determined as a valid change field, and a correspondence is established between the valid change field and the existing configuration option pointed to by the first matching field.

[0009] Optionally, changing the setting status in the initial configuration information according to the valid change field includes: Based on the first matching field, the initial configuration information of the corresponding customer is obtained from the API database, and the configuration options to be changed corresponding to the first matching field are determined in the initial configuration information. Determine the target setting status corresponding to the configuration option to be changed based on the valid change fields; Change the current setting status of the configuration option to be changed to the target setting status; The current setting state and the target setting state are respectively a checked state and an unchecked state. The checked state is used to indicate that the configuration option to be changed is enabled, and the unchecked state is used to indicate that the configuration option to be changed is not enabled.

[0010] Optionally, when the target customer instruction does not have a field match with the sample configuration information, the process of determining the second matching field includes: Read pre-stored sample function information from the API database. The sample function information includes function fields corresponding to the functions that the API platform can provide. The configuration change information carried by the target customer instruction is matched with the function fields. When there is a field in the configuration change information that matches the functional field, the matching functional field is determined as the second matching field; The function to be added corresponding to the target customer instruction is determined based on the second matching field, and the initial configuration information of the corresponding customer is obtained.

[0011] Optionally, the step of generating and adding independent configuration options based on the second matching field includes: The configuration options corresponding to the function to be added are determined based on the second matching field; Add the configuration option to the sample configuration information, so that the added configuration option becomes a configuration field in the sample configuration information; The configuration options are synchronously added to the initial configuration information of the corresponding customer, so as to form independent configuration options corresponding to the functions to be added in the initial configuration information; The setting status of the newly added independent configuration option in the initial configuration information is set to the checked state to enable the function to be added.

[0012] Optionally, when the target customer instruction does not have a field match with the sample function information, the method further includes: Send the target customer instruction and a second error message indicating that the function field matching failed to be sent to the API console; The API console responds to manual processing operations to determine the second matching field corresponding to the target customer's instruction, and receives the second matching field returned by the API console; Based on the returned second matching field, the corresponding configuration option is determined, and the configuration option is added to the sample configuration information and the corresponding customer's initial configuration information, respectively. The setting status of the newly added configuration option in the initial configuration information is determined to be the checked status.

[0013] Optionally, the process of changing existing configuration options may also include: If a valid change field cannot be determined from the target customer instruction based on the first matching field, the target customer instruction and a first error message are sent to the API console; or, When a target change field is extracted from the target customer instruction, but the target change field does not match the sample change field, the target customer instruction and the third error message are sent to the API console. The API console responds to manual processing operations to determine the valid change fields and receives the valid change fields returned by the API console. The target setting state of the corresponding configuration option is determined based on the returned valid change fields, and the current setting state of the configuration option in the initial configuration information of the corresponding customer is changed to the target setting state.

[0014] Secondly, this application provides a granular extension system for API configuration options, the system comprising: The instruction sending module is used to obtain the target customer instruction sent by the API client application server, and the target customer instruction carries configuration change information. The field matching module is used to obtain sample configuration information stored in the API database and perform field matching between the target customer instruction and the sample configuration information; The valid field determination module is used to determine a first matching field when the target customer instruction and the sample configuration information have a field match, extract the target change field corresponding to the first matching field from the target customer instruction, match the target change field with the sample change fields stored in the API database, and determine the successfully matched target change field as a valid change field; The state switching module is used to obtain the initial configuration information stored in the API database that corresponds to the first matching field, and switch the setting state of the corresponding configuration option in the initial configuration information between the enabled state and the disabled state according to the valid change field. The instruction matching module is used to obtain sample function information stored in the API database when there is no field match between the target customer instruction and the sample configuration information, perform field matching between the target customer instruction and the sample function information, and determine the second matching field when there is a field match. The configuration update module is used to generate independent configuration options based on the second matching field, add the independent configuration options to the sample configuration information and the initial configuration information respectively, and set the newly added independent configuration options in the initial configuration information to the enabled state.

[0015] Through the above technical solution, this application achieves the following beneficial effects: By matching the target customer's instructions with the sample configuration information, the existing configuration options corresponding to the target customer's instructions can be automatically identified, and the setting status of the configuration option can be modified according to the valid change fields. This reduces the need for manual searching, manual selection and program modification in the traditional API configuration process, and improves the efficiency of configuration processing.

[0016] After identifying existing configuration options, the system does not directly modify the configuration status. Instead, it matches the target change field extracted from the target customer's command with the sample change field. Only after the target change field is determined to be a valid change field will the setting status of the corresponding configuration option be changed. This reduces the risk of incorrect command field identification, mismatched configuration objects, or accidental modification of setting status.

[0017] When the target customer instruction cannot be matched with the existing sample configuration information, the target customer instruction is further matched with the sample function information, and an independent configuration option corresponding to the function to be added is generated based on the second matching field obtained by the matching. This allows the function that originally needed to be implemented through program customization to be transformed into a configuration option that can be enabled or disabled independently, thereby improving the granularity and flexibility of API configuration.

[0018] After generating configuration options based on the second matching field, these options are synchronously added to the sample configuration information and the corresponding customer's initial configuration information. The configuration options written into the sample configuration information can serve as existing configuration fields for subsequent customer command matching, preventing identical or similar functional requirements from re-entering the custom development process. This facilitates the transformation of individual customer customization needs into reusable API configuration capabilities.

[0019] For customer needs that are not pre-set in the existing configuration system but can match the sample function information, this application can directly generate corresponding independent configuration options and set the configuration options to the checked state in the initial configuration information of the corresponding customer, thereby enabling the corresponding function while completing the configuration extension, reducing the processing steps required for repeated coding, program release and manual deployment.

[0020] The new configuration option simultaneously writes the sample configuration information and the corresponding customer's initial configuration information, so that the common matching basis is expanded synchronously with the customer's actual configuration. This avoids subsequent identification inconsistencies caused by only modifying the customer's configuration without updating the sample configuration, and helps maintain the correspondence between API configuration data.

[0021] For cases where valid change fields cannot be extracted, the target change field fails to match the sample change field, or the target customer instruction fails to match the sample function information, corresponding error messages are generated and sent to the API console. After the API console returns the valid change field or the second matching field, the configuration change or configuration extension can continue to be executed, thereby avoiding the configuration process being interrupted directly due to automatic matching failure.

[0022] By transforming customer configuration requirements into a process of field matching, state switching, and configuration option expansion, the need to repeatedly modify program code for different customers is reduced, the development workload and maintenance complexity in scenarios with a large number of customized customers are reduced, and it is conducive to maintaining the standardization and maintainability of the API configuration system. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a method for granular extension of API configuration options provided in an embodiment of this application; Figure 2 This is a schematic diagram of a granular extension system architecture for API configuration options provided in an embodiment of this application. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0026] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0027] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0028] Example 1 Currently, routine changes to API (Application Programming Interface) platform configurations primarily rely on manual settings, failing to achieve automation and exhibiting low levels of intelligence. Furthermore, existing configuration schemes are mostly fixed templates, lacking customization capabilities to meet specific customer needs; even the few customized schemes that exist fail to achieve modular and granular management of configuration items. When faced with numerous diverse customer requirements, large-scale modifications to the program are often necessary, significantly increasing development workload, resulting in high maintenance costs and low efficiency. Simultaneously, manual operation is highly susceptible to human error, leading to inconsistent configurations, version conflicts, and compromised system stability.

[0029] Please see Figure 1 This is a flowchart of a granular extension method for API configuration options provided in an embodiment of this application. The method includes: Step 1: Obtain the target client instruction sent by the API client application server. The target client instruction carries configuration change information. The target client instruction refers to a control signal initiated by the client to instruct the API platform to adjust configurations. This instruction originates from the API client application server and is typically generated by the client server after receiving a user's selection of a specific configuration tag. Configuration change information can be the core data carried in the instruction, and its specific form can be key-value pairs, JSON objects, or XML fragments, describing the name of the configuration item the user expects to change and its anticipated state change. For example, configuration change information could contain `{option_id:rate_limit,action:enable}`, indicating that the user wants to enable rate limiting. This step aims to establish a communication bridge between the system and user needs, receiving external requests through a standardized instruction format to provide an accurate input data source for subsequent automated processing.

[0030] Step Two: Retrieve sample configuration information stored in the API database and perform field matching between the target customer command and the sample configuration information. The sample configuration information refers to a structured data set pre-stored in the API database that represents existing standard configuration options on the platform. This information includes all directly reusable configuration field definitions, such as field names, data types, and default attributes. Field matching refers to the process of comparing the configuration identifier in the target customer command with the standard fields in the sample configuration information item by item. Specifically, the system reads the sample configuration information from the API database, extracts the list of configuration fields, and then iterates through the configuration change information carried by the target customer command, searching for entries that are completely identical or semantically matched to fields in the list. For example, if the sample configuration information contains a `timeout_setting` field, and the target command also carries `timeout_setting`, then a successful match is determined. The purpose of this step is to quickly identify whether the user's intent pertains to an operation on existing mature configuration items, thereby determining whether the subsequent process enters a state switching branch or a new feature expansion branch.

[0031] Step 3: When there is a field match between the target customer instruction and the sample configuration information, determine the first matching field, extract the target change field corresponding to the first matching field from the target customer instruction, match the target change field with the sample change field stored in the API database, and determine the successfully matched target change field as the valid change field; The first matching field refers to a standard field in the sample configuration information that has been confirmed to exist during the matching process. It clearly points to the specific configuration option that the user wants to operate on. The target change field is the parameter content extracted from the target customer's instruction, which indicates how the configuration option will change, such as instruction fragments like "on," "off," or "value adjusted to X." The sample change field is a predefined set of legal state change operations in the API database, used to verify the compliance of user instructions. A valid change field is a target change field that has been confirmed as legal and executable after comparison with sample change fields. Specifically, after determining the first matching field, the system parses the action description associated with that field in the instruction, uses it as the target change field, and performs a secondary match with the sample change field library in the database (such as {enable, disable, reset}). Only when the target change field exists in the sample change field library is it marked as a valid change field. For example, if the user instruction requests a permanent lock, but the sample change field library only defines a temporary disable, the instruction will not match successfully and will not be determined as a valid change field; conversely, if the instruction is to disable, the match will be successful and it will be confirmed as valid. By combining the first matching field with the valid change field, the system not only identifies the object of the operation but also verifies the legality of the operation, ensuring the security and standardization of configuration changes.

[0032] Step 4: Obtain the initial configuration information stored in the API database that corresponds to the first matching field, and switch the setting status of the corresponding configuration option in the initial configuration information between enabled and disabled states based on the valid change fields; The initial configuration information refers to a snapshot of the actual configuration belonging to a specific customer, currently stored in the API database. It records the current running status of each configuration option for that customer. The setting status refers to the logical on / off state of the configuration option, specifically enabled or disabled, corresponding to checked and unchecked states on the interface. An enabled state indicates that the corresponding functional module is in active running mode, while an disabled state indicates that the functional module is in dormant or disabled mode. In practice, the system locates the configuration record to be changed in the initial configuration information based on the first matching field, reads its current setting status, and then performs a flip operation based on the indication of the valid change field: if the valid change field indicates enabled and it is currently disabled, it is switched to enabled; if it indicates disabled and it is currently enabled, it is switched to disabled. For example, for the log auditing configuration option, if its initial state is disabled, but the valid change field confirms it is enabled, the system flips the option's status bit from 0 to 1, taking effect immediately. This step achieves an automated closed loop for configuration changes, requiring no manual code modification, and can accurately and quickly respond to customer needs for starting or stopping existing functions, significantly improving operational efficiency.

[0033] Step 5: When there is no field match between the target customer instruction and the sample configuration information, retrieve the sample function information stored in the API database, match the target customer instruction with the sample function information, and determine the second matching field if a field match exists. Here, sample function information refers to a set of potential functions stored in the API database that describe the platform's capabilities but have not yet been instantiated in the current configuration instance. Unlike sample configuration information, sample function information focuses on the definition of function semantics rather than the specific configuration parameter structure. The second matching field can be a function identifier identified in the sample function information that matches the semantics of the target customer's instruction. This step constitutes the second path of this method, specifically for handling scenarios involving new requirements. When the above matching fails, it means that the function requested by the user is not in the existing configuration template, and the system automatically switches to the sample function library for retrieval. The system performs semantic analysis or string matching between the keywords or function descriptions in the target customer's instruction and the function fields in the sample function information. For example, if the user instruction includes support for MQTT protocol access, but this option is not present in the sample configuration information, yet the MQTT_Protocol_Support function definition exists in the sample function information, then the system identifies this function definition as the second matching field. This mechanism ensures that the system can intelligently identify the user's customized extension intent, laying the foundation for dynamically generating new configuration items.

[0034] Step 6: Generate independent configuration options based on the second matching field, add the independent configuration options to the sample configuration information and the initial configuration information respectively, and set the newly added independent configuration options in the initial configuration information to the enabled state; The independent configuration option refers to a new configuration entity dynamically constructed based on the second matching field, with complete attribute definitions. The generation process involves instantiating a standard configuration object based on the metadata associated with the second matching field (such as default parameters, dependencies, and UI display attributes). Adding this independent configuration option to the sample configuration information means incorporating the new feature into the platform's standard configuration dictionary, making it a common asset that other customers can also choose; adding it to the initial configuration information means immediately deploying the new feature to the configuration environment of the currently requesting customer. Setting it to an enabled state means that after the new configuration option is created, its logical state is automatically initialized to active mode, allowing direct use without user confirmation. For example, when the second matching field is determined to be MQTT_Protocol_Support, the system automatically generates an independent configuration option named MQTT Access Switch, sets its default port to 1883, writes this option to the sample configuration library for global reuse, and simultaneously writes it to the current customer's initial configuration table and immediately sets it to enabled. Through the above steps, this application achieves granular dynamic expansion of configuration, transforming the originally code-driven customized requirements into a data-driven configuration generation process, greatly reducing development costs and shortening the delivery cycle.

[0035] Example 2 In another optional embodiment, a target customer instruction acquisition process is provided, the method further comprising: Step 1: Establish a communication connection between the API client application server and the client client; The communication connection refers to the logical channel or physical link between the API client application server and the client application server for data transmission. This communication connection is established through the network protocol stack initialization handshake process, ensuring stable and low-latency data interaction between the two devices. Specifically, the API client application server acts as the receiver of configuration processing, while the client application server acts as the front-end entry point for user interaction. Both establish a long-lived connection or session connection via TCP / IP or an application layer protocol based on HTTP / HTTPS. For example, when the client application server starts or detects a user login event, it proactively initiates a connection request to the API client application server. After a three-way handshake, the communication link is established, and a heartbeat mechanism is maintained to keep the connection active. By establishing this communication connection, a reliable basic channel is provided for the real-time transmission of subsequent configuration change information, ensuring the connectivity of data interaction.

[0036] Step 2: Receive the customer's selection operation for the configuration tag through the customer service terminal, and generate the target customer instruction carrying configuration change information based on the selected configuration tag; Configuration tags refer to interactive controls preset on the client-side interface that represent specific API function modules or parameter options. These include switch-type tags, drop-down selection tags, and multi-select checkboxes. Selection is a triggered action by the client through mouse clicks, touch swipes, or keyboard input. The target client instruction is a structured data message automatically generated based on the state change of the selected configuration tag. Its source is the client-side's monitoring and encapsulation of user interaction events. The purpose of this instruction is to accurately map the user's configuration intent, transforming unstructured operations into machine-readable configuration change requests. Specifically, the client-side monitors the status of configuration tags on the interface in real time. When a status change is detected (e.g., from unchecked to checked), it extracts the unique identifier (ID) corresponding to the tag and the expected target state value, assembling them into a target client instruction conforming to a preset protocol format. For example, if the user checks the configuration tag for enabling rate limiting protection on the front-end interface, the client-side immediately generates a target client instruction containing the fields {feature_id:rate_limit,status:enable}. This tag-based interaction and automated command generation mechanism effectively reduces the error rate of customers manually entering configuration codes and ensures the standardization and completeness of command content.

[0037] Step 3: The client-side sends the target customer's instruction to the API client application server to trigger the API configuration processing for the corresponding customer.

[0038] The sending process refers to the client-side transmitting the generated target client instruction data packet to the API client application server using the established communication connection. This sending is executed based on the established communication link and its function is to initiate the backend configuration update logic. Specifically, the client-side serializes the target client instruction into a binary stream or JSON text and pushes it to the API client application server via a Socket socket or RESTful interface. After receiving the instruction, the API client application server parses the configuration change information and immediately triggers the field matching and configuration switching process described in the above embodiment. For example, the client-side sends the instruction packet carrying the configuration change information to a specific URL endpoint on the server via an HTTPS POST request, and the server immediately enters the processing queue upon receiving it. Thus, an end-to-end closed loop is achieved from front-end user operation to backend configuration execution, ensuring that configuration change requests are responded to and processed by the system in a timely and accurate manner.

[0039] Example 3 In one embodiment, a method is provided for matching target customer instructions with sample configuration information and determining a first matching field, including the following steps: Step 1: Read the pre-stored sample configuration information from the API database. The sample configuration information includes the configuration fields corresponding to the existing configuration options in the API platform. The sample configuration information refers to a set of verified standard configurations accumulated by the API platform during its initialization phase or historical operation. Essentially, it is a structured data table or a collection of key-value pairs. Specifically, this sample configuration information includes configuration fields corresponding to all online functional modules in the API platform. Each configuration field uniquely corresponds to an existing configuration option, such as rate limiting threshold switch, protocol version selection, and log recording level. These configuration fields serve as a whitelist or standard dictionary on the platform side, defining the scope of configurations that the system can currently recognize and process. The sample configuration information is predefined by the system administrator in the API console and stored in the API database, or it is automatically generated during system upgrades. Its purpose is to serve as a benchmark for subsequent field matching, ensuring that change requests initiated by customers only operate on legitimate configuration items supported by the platform, preventing the injection of illegal commands. For example, the sample configuration information may include the fields RateLimit_Enable (corresponding to the rate limiting enable option), Protocol_Version (corresponding to the protocol version option), and Log_Level (corresponding to the log level option). By establishing this standardized sample configuration information database, the system can quickly locate the specific business scenario indicated by the customer's instruction, providing a data foundation for subsequent accurate matching.

[0040] Step Two: Match the configuration change information carried by the target customer's instruction with each configuration field. This item-by-item matching refers to the system processor traversing all configuration change key-value pairs carried in the target customer's instruction and comparing each key name (Key) or semantic identifier with the configuration fields in the sample configuration information read above. This matching process can employ precise string matching algorithms or perform semantic similarity calculations based on natural language processing technology to determine whether the change intent in the instruction is consistent with the platform's preset configuration fields. The configuration change information is the core payload of the target customer's instruction, typically encapsulated in JSON or XML format, containing the specific parameter names and expected values ​​that the customer wishes to modify. This step is executed by the API configuration processing engine, whose input conditions are based on the complete set of sample configuration information obtained above and the target customer instruction received in Step S1. Through item-by-item matching, the system can filter out irrelevant noise data or non-standard custom parameters in the instruction, retaining only valid request fragments compatible with the platform's standard configuration system. For example, if the target customer's instruction contains {setting:open_log,value:true}, the system will compare the value of the setting field, open_log, with fields such as Log_Level and Log_Switch in the sample configuration information. If an association is found between open_log and Log_Switch in the semantic mapping table, a successful match is determined. This item-by-item comparison mechanism effectively avoids matching omissions caused by differences in field naming, improving the system's fault tolerance and intelligence level.

[0041] Step 3: When there is a field in the configuration change information that matches the configuration field, the matching field is identified as the first matching field, and the existing configuration option pointed to by the target customer's instruction is determined based on the first matching field; The first matching field refers to the specific field that, during the item-by-item matching process described above, is confirmed to be completely identical or semantically equivalent to a configuration field in the sample configuration information. Determining the first matching field essentially maps the non-standardized description on the client side to the standardized configuration entity on the platform side. Once the first matching field is determined, the system immediately uses a pre-stored mapping table to look up the specific existing configuration option bound to that field. Existing configuration options can refer to functional units that actually exist on the API platform and can be perceived and manipulated by the user, such as enabling HTTPS forced redirection or enabling IP whitelist filtering. There is a one-to-one or many-to-one logical association between the first matching field and existing configuration options; this association is stored in the metadata table of the API database. Determining existing configuration options through the first matching field establishes a strong connection from the command text to the system function, ensuring the accuracy of subsequent operation objects. For example, when the first matching field is SSL_Force, the system determines that the existing configuration option it points to is the HTTPS forced enable policy based on the mapping relationship. This process not only locks the operation target but also implicitly loads the current state, permission level, and other attributes of the configuration option, providing a complete context environment for subsequent state changes.

[0042] Step 4: Extract the target change field from the target customer instruction to indicate the change in the setting status of existing configuration options.

[0043] The target change field refers to a specific data field in the target customer instruction, besides the identifier field used to locate configuration options, that describes the state to which the option needs to be changed. The target change field typically contains a status identifier (such as enable, disable, true, false) or a specific parameter value. Extracting the target change field is performed after determining the first matching field and its corresponding existing configuration option; its purpose is to obtain the customer's explicit change intent. The source of the target change field is the payload of the target customer instruction. The system parses the corresponding status value from the instruction structure based on the type definition of the first matching field. For example, if the first matching field points to a current limit switch, the target change field might be the `status:on` part of the instruction; if it points to a timeout, the target change field might be `timeout:30s`. This field directly drives the subsequent configuration update logic, determining whether the existing configuration option is switched from enabled to disabled, or vice versa. By accurately extracting the target change field, the system can distinguish between query operations and change operations, ensuring that only requests carrying explicit status change instructions trigger the write operation of configuration information, thereby guaranteeing the security and consistency of configuration data.

[0044] Example 4 In an optional implementation, this application also provides a process for determining valid change fields. This process is executed after confirming that there is a field match between the target customer instruction and the sample configuration information (i.e., the first matching field has been determined), and is intended to perform a legality verification on the extracted target change fields.

[0045] Step 1: Read the pre-stored sample change fields from the API database. The sample change fields are used to represent the setting status changes corresponding to the configuration options. Sample change fields refer to a set of state change operations that the API platform predefines and stores in the database, allowing users to perform on configuration options. These fields constitute a platform-level change whitelist, used to define which state transitions are supported and legal by the system. The specific content of sample change fields typically includes standardized codes or identifiers indicating semantics such as enable, disable, turn on, turn off, check, or decheck. For example, sample change fields may include the code ENABLE_01 representing the enabled state and the code DISABLE_01 representing the disabled state; these two fields correspond to the legal instructions to switch a configuration option from its current state to enabled or disabled, respectively. By pre-setting these sample change fields, the system can filter out non-standard, misspelled, or platform-unsupported change requests that may exist in customer instructions, thereby ensuring the security of subsequent configuration modification operations.

[0046] Step 2: Match the target change fields extracted from the target customer's instructions with the sample change fields; The target change field is a specific data item parsed from the target customer instruction sent by the customer, indicating an intention to change the state of a certain configuration option. This step is executed by the API configuration processing module, which verifies the compliance of the target change field by comparing it item by item with the sample change field library read above. The matching process can employ methods such as exact string matching, hash value comparison, or predefined mapping table lookup. For example, if the target change field extracted from the target customer instruction is SET_ACTIVE_TRUE, the system will logically map it to ENABLE_01 in the sample change field library; if the extracted field is the invalid FORCE_OPEN_X, no corresponding item can be found in the sample change field library. The core function of this step is to filter invalid instructions; only when the target change field falls within the legal range defined by the sample change field is it considered a potentially valid basis for change.

[0047] Step 3: When the target change field matches the sample change field, the matching target change field is determined as the valid change field, and a correspondence is established between the valid change field and the existing configuration option pointed to by the first matching field.

[0048] In this context, a valid change field refers to a state change instruction that has been confirmed as legal and executable after the aforementioned matching verification. Once the target change field successfully matches the sample change field, the system marks it as a valid change field. Simultaneously, the system establishes an explicit binding relationship between this valid change field and the first matching field (i.e., the existing configuration option that has been matched). This correspondence clarifies which configuration option needs to be adjusted according to which legal state change content. For example, when the first matching field points to the log auditing function configuration item, and the target change field is successfully matched and confirmed as the valid change field DISABLE_01, the system establishes a correspondence between the log auditing function and the disabled state. By establishing this strong correspondence, the uniqueness and accuracy of configuration state switching operations in subsequent steps are ensured, avoiding configuration errors caused by instruction ambiguity.

[0049] Example 5 In another optional embodiment, this application also provides a specific implementation method for changing the setting status in the initial configuration information based on the valid change field.

[0050] Step 1: Based on the first matching field, retrieve the initial configuration information of the corresponding customer from the API database, and determine the configuration options to be changed in the initial configuration information that correspond to the first matching field; The initial configuration information can refer to configuration files or data records stored in the API database that record the current API functionality enabled status for a specific customer. This initial configuration information is obtained by querying the database index, using the first matching field determined in the previous steps as the retrieval key. The first matching field uniquely identifies the existing configuration option that the customer requests to modify, such as the number of days to retain logs or the concurrent connection limit. The configuration option to be changed is the specific parameter item in the initial configuration information that is directly associated with the first matching field. Specifically, the system locates the specific row or node in the customer's dedicated configuration table based on the identifier (such as ID or name) of the first matching field and marks it as the configuration option to be changed. For example, if the first matching field is RateLimit_Enable, the system locates the field with the key RateLimit_Enable in customer A's initial configuration JSON file, and this field is the configuration option to be changed. This precise location based on the first matching field ensures that subsequent operations are only performed on the target configuration item, avoiding accidental modification of other unrelated configurations and guaranteeing the atomicity of configuration updates.

[0051] Step 2: Determine the target setting status corresponding to the configuration option to be changed based on the valid change fields; The valid change field is extracted from the target customer's instruction and successfully validated using sample change fields. It represents the final state the customer expects to achieve. The target setting state can refer to the logical value that the configuration option to be changed should have after the update. The role of the valid change field is to carry the instruction information for state switching. The system deduces the target setting state by parsing the content of this field. Specifically, the valid change field usually contains a status indicator or action instruction. The system has preset mapping rules to convert the values ​​or characters in the valid change field into internal logical states. For example, when the content of the valid change field is true, 1, or enable, the determined target setting state is enabled; when the content is false, 0, or disable, the determined target setting state is disabled. Through the mapping relationship between the valid change field and the target setting state, a standardized conversion from client instructions to the system's internal logical state is achieved, eliminating parsing ambiguities caused by differences in the format sent by different clients.

[0052] Step 3: Change the current setting status of the configuration option to be changed to the target setting status; The current setting state represents the original state of the configuration option to be changed in the database before it is modified, while the target setting state is the expected state derived from the above analysis. This step is executed by the API configuration processing module, which overwrites and updates the values ​​of fields in the database. The change process is an atomic operation; that is, the process of reading the current value, comparing it with the target value, and writing the new value is completed within a transaction to ensure data consistency. Specifically, the system updates the value of the configuration option to be changed in memory to the target setting state and synchronously persists it to the API database. For example, if the current setting state of the log auditing function of the configuration option to be changed is unchecked, but the target setting state determined based on the valid change field is checked, then the system updates the value of that field in the database from 0 to 1. This direct state overwrite mechanism ensures that the customer's configuration change instructions take effect immediately without requiring a service restart or reloading of the entire configuration file.

[0053] The current setting status and the target setting status are respectively a checked state and an unchecked state. The checked state indicates that the configuration option to be changed is enabled, and the unchecked state indicates that the configuration option to be changed is not enabled.

[0054] Specifically, the checked state is represented by a selected checkbox in the user interface, corresponding to a Boolean value of True or an integer of 1 in the underlying data storage. Technically, this activates the corresponding API function module, making that function effective for client requests. The unchecked state is represented by an unselected checkbox in the user interface, corresponding to a Boolean value of False or an integer of 0 in the underlying data storage. Technically, this deactivates the corresponding API function module, and the system will ignore or reject requests involving that function. By defining these two mutually exclusive and explicit states of checked and unchecked, the system simplifies complex business configurations into binary logical judgments, not only reducing the complexity of configuration management but also significantly improving the accuracy and traceability of configuration change operations.

[0055] Example 6 In one optional implementation, a process for determining a second matching field when no matching field exists and a method for obtaining initial configuration information are provided, including: Step 1: Read the pre-stored sample function information from the API database. The sample function information includes the function fields corresponding to the functions that the API platform can provide. The sample function information refers to the collection of all configurable functions supported by the current version of the API platform, derived from the function registry during system initialization or a dynamically updated function library. The sample function information consists of multiple function entries, each corresponding to an independent function module, such as authentication, traffic control, and log auditing. Function fields are unique identifiers of these function modules, represented by characteristic strings or codes. These function fields serve as a structured index of the platform's capabilities, used for semantic comparison with client instructions in subsequent steps. Function fields can be dynamically updated based on platform function iterations. When a new function module is added, the corresponding function field is registered in the sample function information. For example, when the API platform adds OAuth2.0 protocol support, the function field FUNC_AUTH_OAUTH2 is written into the sample function information, establishing a one-to-one mapping between this field and the function module. This pre-defined function field library transforms clients' ambiguous natural language requirements into standard identifiers recognizable by the system, providing a data foundation for subsequent automated matching.

[0056] Step 2: Match the configuration change information carried by the target customer's command with the function fields; Field matching refers to the process of comparing the configuration change information carried in the target customer's instruction with the aforementioned function fields one by one. Configuration change information typically includes descriptive text, keywords, or code identifiers of the functions the customer expects to change or add. Matching can be based on exact string matching or fuzzy matching based on semantic similarity. A successful match is determined when the configuration change information is completely identical to a function field or falls within a preset similarity threshold. For example, if the configuration change information in the target customer's instruction requires enabling OAuth2 authentication, the system compares the keyword "OAuth2" with the function field "FUNC_AUTH_OAUTH2" in the sample function information. If the preset rule defines that the two are semantically equivalent, a successful match is determined. This step aims to quickly filter out target functions that match the customer's intent from a vast array of platform functions, ensuring the accuracy of newly added configuration options.

[0057] Step 3: When a field matching the function field exists in the configuration change information, the matching function field is identified as the second matching field; The second matching field refers to the functional field that was successfully matched during the above matching process. It represents the specific functional requirement to be added, as indicated by the target customer's instruction. The determination of the second matching field signifies that the system has successfully parsed the customer's customized needs and mapped them to the platform's existing capability pool. The second matching field serves as the core basis for generating subsequent independent configuration options, directly determining what type of configuration item will be added to the initial configuration information. For example, if the successfully matched functional field is FUNC_RATE_LIMIT_ADVANCED, then this field is determined as the second matching field, indicating that the system needs to add advanced rate limiting-related configuration options for the customer. By establishing the second matching field, the conversion from unstructured customer instructions to structured functional identifiers is achieved, ensuring the standardization of configuration extensions.

[0058] Step 4: Determine the function to be added corresponding to the target customer's instruction based on the second matching field, and obtain the initial configuration information of the corresponding customer.

[0059] The feature to be added can refer to a specific business function module mapped by the second matching field, such as advanced rate limiting or OAuth2 authentication. The process of determining the feature to be added is completed by querying the mapping table between the function field and the function description, which clarifies the specific content to be added to the customer's configuration. Simultaneously, obtaining the corresponding customer's initial configuration information can refer to retrieving the customer's current configuration snapshot from the API database. This snapshot contains all the configuration options enabled by the customer and their status. The source of the initial configuration information is the configuration record table stored for each customer ID in the API database. The purpose of obtaining the initial configuration information is to provide a data carrier for subsequently merging the configuration options of the new feature into the existing configuration, ensuring that the new operation does not overwrite or destroy the original valid configuration. For example, after determining that the feature to be added is an enhanced log version, the system immediately loads the initial configuration information of customer A (including basic log on / off settings, retention days, etc.) to insert the independent configuration options of the enhanced log version on this basis. This step, by performing function identification and data preparation simultaneously, significantly improves the coherence and execution efficiency of the configuration extension process.

[0060] Example 7 In one optional embodiment, a method is provided for generating and adding independent configuration options and enabling the added functionality based on a second matching field, including: Step 1: Determine the configuration options corresponding to the feature to be added based on the second matching field; Configuration options refer to logical units within the API platform used to control the enabling or disabling of specific functions. These options can manifest as Boolean fields in a database, key-value pairs in a configuration table, or checkboxes in a front-end interface. The configuration option is obtained by parsing the functional semantics pointed to by the second matching field. This second matching field originates from the matching result between the target client's instructions and the sample functional information, serving as an index key to retrieve standardized configuration description information from a predefined functional mapping table. For example, when the second matching field indicates HTTP2 protocol support, the system automatically determines the corresponding configuration option as `enable_http2_protocol`, which corresponds to a 1-bit flag in the underlying data structure. This semantic mapping-based determination method transforms ambiguous client functional requirements into standard configuration entities recognizable by the system, ensuring compatibility between new options and the platform's existing architecture.

[0061] Step 2: Add the configuration options to the sample configuration information, making the added configuration options configuration fields in the sample configuration information; The sample configuration information is a global configuration template stored in the API database, containing a set of definitions for all currently available configuration options on the platform. Adding a configuration option to the sample configuration information involves inserting a new record into the configuration metadata table. This record contains the configuration option's name, data type, default value, and description, thus formally making it part of the platform's configuration fields. This process dynamically expands the platform's capability baseline, ensuring that newly generated configuration options are visible not only to current customers but also to all subsequently connected customers. For example, if the determined configuration option is a custom rate limiting rule, after the system writes it into the dictionary list of the sample configuration information, this field becomes a member of the platform's standard configuration set, and any newly registered customer can read this field definition during initialization. By solidifying new options into sample configuration fields, configuration fragmentation caused by temporary customization is avoided, ensuring the consistency and maintainability of the platform's configuration system.

[0062] Step 3: Synchronize the configuration options to the corresponding customer's initial configuration information, so as to form independent configuration options corresponding to the functions to be added in the initial configuration information; The initial configuration information is a personalized configuration dataset generated for a specific customer instance, recording all currently active configuration items and their status for that customer. Synchronous addition refers to copying and instantiating new configuration options already included in the sample configuration information into the specific customer's configuration record, forming a unique, independent configuration option. This independent configuration option is logically independent of other customers' configurations, but structurally maintains the same origin as the sample configuration information. Specifically, upon detecting an update to the sample configuration information, the system immediately triggers a configuration synchronization mechanism for the current session customer, appending new key-value pairs to the customer's configuration JSON object or database row. For example, for customer A, the system appends the `enable_http2_protocol` field to its unique configuration document, at which point this field becomes an independent control node in customer A's configuration space. This bidirectional synchronization mechanism ensures that the evolution of the platform's global capabilities can be instantly mapped to the individual customer's runtime environment, achieving fine-grained expansion of configuration granularity.

[0063] Step 4: Set the newly added independent configuration options in the initial configuration information to the checked state to enable the added functions.

[0064] The setting status indicates the activation status of configuration options, including a checked state and an unchecked state. A checked state indicates the function is enabled, while an unchecked state indicates the function is disabled. Specifically, setting the setting status to checked is achieved by directly initializing the corresponding boolean value or flag to True or 1 when generating the independent configuration option, without requiring secondary confirmation from the customer. This mechanism embodies the out-of-the-box design principle, ensuring that newly added functions requested by the customer take effect immediately upon configuration generation. For example, when a custom rate limiting rule is synchronized to customer A's initial configuration information, the system automatically marks its status as checked, and the API gateway then loads the corresponding rate limiting algorithm module to manage the customer's traffic. By defaulting to an enabled state for newly added options, the step of manual activation by the customer is eliminated, significantly improving the response speed and user experience for customized needs.

[0065] Example 8 In one optional embodiment, a method is provided for manually determining a second matching field and updating the configuration when a functional field fails to match, including: Step 1: Send the target customer instruction and a second error message indicating that the function field failed to match to the API console; The target customer instruction is the original instruction that, as determined, does not match any field in the sample function information. It carries configuration change information for the customer's desired new function. The second error message is an automatically generated exception identifier signal, used to clearly indicate that the current automated process has been blocked at the function semantic matching stage, meaning that there is currently no function definition matching the customer instruction in the system's pre-stored sample function information database. The API console, as the central governance node in this embodiment, has a human-computer interaction interface and management permissions, used to receive exception requests from the automated process and schedule human resources for intervention. Specifically, when the executing entity detects that the configuration change information in the target customer instruction cannot establish a mapping relationship with any pre-stored function fields in the API database, it immediately triggers the exception handling mechanism, constructs a data packet containing the original instruction data and the second error message, and pushes it to the message queue of the API console through an internal communication protocol. For example, if a customer instruction includes a new requirement—supporting quantum encrypted transmission—that is not defined in the existing function library, the system, after searching through the sample function information and failing to find the corresponding field, generates a second error message with the error code FUNC_MATCH_FAIL. This message, along with the instruction, is sent to the API console's management interface, awaiting a response from operations experts or configuration administrators. This automatic reporting mechanism ensures that in long-tail scenarios not covered by automated logic, the system process remains uninterrupted and user requests are not discarded, providing a complete data context for subsequent manual intervention.

[0066] Step 2: Determine the second matching field corresponding to the target customer's instruction through the API console in response to the manual processing operation, and receive the second matching field returned by the API console; The second matching field, after manual analysis and confirmation, is a standard function identifier that accurately represents the new function indicated by the target customer's instruction. Upon receiving the second error message, the API console displays a list of pending tasks and the corresponding details of the target customer's instruction, allowing authorized personnel to perform semantic analysis and decision-making. Manual processing includes reviewing the instruction content, searching an external knowledge base, or selecting the most matching function from the platform's potential function set based on business planning, and standardizing it as the second matching field. This process achieves collaboration between AI automation and human expert experience, resolving matching failures caused by new business launches lagging behind customer needs or ambiguous semantic expressions. Specifically, the configuration administrator reviews unmatched instructions on the API console interface, confirms that the actual intention is to enable a high-level function not yet in the database, and then selects or enters the corresponding standard function code as the second matching field in the console, submitting a confirmation operation. The API console then encapsulates this second matching field in a response message and sends it back to the server executing this method. For example, regarding the aforementioned quantum-encrypted transmission command, the administrator identified the corresponding advanced security protocol module in the platform's planning within the console. The administrator then determined the preset ADV_SEC_PROTO_01 field as the second matching field and returned it. Thus, the system successfully obtained the previously missing key mapping relationship, transforming the unstructured client's natural language requirements into structured functional fields recognizable by the system, laying the foundation for subsequent configuration generation.

[0067] Step 3: Determine the corresponding configuration options based on the returned second matching field, add the configuration options to the sample configuration information and the corresponding customer's initial configuration information respectively, and set the setting status of the newly added configuration options in the initial configuration information to the checked state; The configuration options are specific control switches dynamically instantiated based on the second matching field, used to enable this new feature on the API platform. The sample configuration information serves as a platform-wide configuration template; its update signifies that the new feature has been formally incorporated into the platform's standard service capability pool. The initial configuration information for the corresponding customer, however, is a personalized configuration set for a specific tenant, and its update directly affects that customer's business environment. Setting the setting to the checked state directly enables the feature without requiring secondary confirmation from the customer, demonstrating a rapid response capability to urgent or customized needs. Specifically, the execution entity parses the received second matching field, calls the configuration generation engine, and creates a new configuration item (such as a checkbox or switch control) bound to the feature. Subsequently, the system performs a double write operation: first, the new configuration item is appended to the sample configuration information list in the API database, making it a standard reference for subsequent matching by other customers; second, the new configuration item is synchronously inserted into the initial configuration file of the specific customer initiating the request, and its boolean attribute is forcibly set to True or a checked state. This mechanism not only meets the current customized needs of customers in a timely manner, but also enables the continuous evolution and self-improvement of the platform's function library by feeding back sample configuration information, effectively avoiding the accumulation of technical debt due to frequent modifications to the underlying code caused by single customer needs.

[0068] Example 9 In one optional embodiment, a method is provided for manually determining valid change fields and updating their status during existing configuration option change processing, including: Step 1: When a valid change field cannot be determined from the target customer instruction based on the first matching field, the target customer instruction and the first error message are sent to the API console; or, when the target change field is extracted from the target customer instruction, but there is no field match between the target change field and the sample change field, the target customer instruction and the third error message are sent to the API console. This step aims to build an anomaly capture and triage mechanism for semantic uncertainty in configuration changes. The first matching field can refer to the field that successfully matches the sample configuration information, used to locate the existing configuration option to be changed. If a clear change intent cannot be parsed from the instruction content corresponding to this field (i.e., a valid change field cannot be determined), the first anomaly scenario is triggered. The first error message generated at this time is used to indicate that the change intent is missing or the instruction format is incomplete. For example, when the customer instruction only contains the modification of the rate limiting configuration without specifying a specific threshold value or switching direction, the system determines that a valid change field cannot be extracted, and then encapsulates the instruction and the first error message and sends them to the API console. The third error message corresponds to the second anomaly scenario, that is, although the target change field (such as threshold = 500) is extracted, the content or format of the field does not match the sample change field library pre-stored in the API database (for example, the sample library only defines boolean enable / disable, while the customer instruction provides a numerical parameter). In this case, the system sends the target customer instruction together with the third error message, where the third error message is clearly identified as a change parameter type mismatch or a non-standard change request. By distinguishing between the first and third error messages, the API console can quickly identify whether the root cause of the exception stems from a missing instruction or a conflict in parameter definitions, thus providing accurate contextual information for subsequent manual intervention.

[0069] Step 2: Determine the valid change fields in response to manual processing operations via the API console, and receive the valid change fields returned by the API console; This step seamlessly integrates automated processes with expert human intervention. The API console, acting as a human-computer interaction management terminal, receives a target customer instruction with an error message and displays the exception details and the original instruction to operations and maintenance personnel or configuration administrators. Manual processing refers to the process by which professionals perform semantic analysis and correction of the abnormal instruction based on business rules, customer needs, and the system's current sample change field definitions. For example, in the case of a threshold of 500 that does not match the sample database, a human operator can confirm that the numerical change is a legitimate new requirement and map it to a valid change field recognized internally by the system (e.g., standardizing it as rate limiting threshold_new type=500); or, in cases where the instruction is missing, the operator can manually supplement the specific change parameters. The valid change field generated after manual confirmation has a data structure fully compatible with the sample change fields, ensuring the legitimacy of subsequent execution. The system polls or listens for callbacks from the API console through a preset data interface, receiving this manually verified valid change field in real time, thereby transforming unstructured abnormal requests into structured executable instructions.

[0070] Step 3: Determine the target setting status of the corresponding configuration option based on the returned valid change fields, and change the current setting status of the configuration option in the initial configuration information of the corresponding customer to the target setting status.

[0071] This step ensures the finalization of the configuration state under the abnormal branch. The target setting state is the specific configuration value obtained by parsing the received valid change fields, including enabled (checked) or disabled (unchecked) states, or specific parameter values. The system uses the returned valid change fields to relocate the configuration option to be changed, as pointed to by the first matching field, reads its current setting state in the initial configuration information, and forcibly updates it to the target setting state. For example, if a manually determined valid change field indicates enabling advanced logging, the system will switch the advanced logging option's state in the corresponding customer's initial configuration information from disabled to enabled. This process not only repairs the configuration flow interrupted by automatic matching failures but also ensures the accurate implementation of customer customization needs, avoiding business stagnation caused by the system rigidly rejecting non-standard instructions.

[0072] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0073] Figure 2 This is a schematic diagram of the structure of an API configuration option granular extension system provided in an embodiment of this application, as shown below. Figure 2 As shown, the API configuration option granular extension system 300 in this embodiment includes: an instruction sending module 301, a field matching module 302, a valid field determination module 303, a state switching module 304, an instruction matching module 305, and a configuration update module 306.

[0074] Instruction sending module 301 is used to obtain target customer instructions sent by API client application server, wherein the target customer instructions carry configuration change information; The field matching module 302 is used to obtain sample configuration information stored in the API database and perform field matching between the target customer instruction and the sample configuration information; The valid field determination module 303 is used to determine a first matching field when there is a field match between the target customer instruction and the sample configuration information, extract the target change field corresponding to the first matching field from the target customer instruction, match the target change field with the sample change fields stored in the API database, and determine the successfully matched target change field as a valid change field. The state switching module 304 is used to obtain the initial configuration information stored in the API database that corresponds to the first matching field, and switch the setting state of the corresponding configuration option in the initial configuration information between the enabled state and the disabled state according to the valid change field. The instruction matching module 305 is used to obtain sample function information stored in the API database when there is no field match between the target customer instruction and the sample configuration information, perform field matching between the target customer instruction and the sample function information, and determine the second matching field when there is a field match. The configuration update module 306 is used to generate independent configuration options based on the second matching field, add the independent configuration options to the sample configuration information and the initial configuration information respectively, and set the newly added independent configuration options in the initial configuration information to the enabled state.

Claims

1. A method for granular extension of API configuration options, characterized in that, include: S1. Obtain the target customer instruction sent by the API client application server, wherein the target customer instruction carries configuration change information; S2. Obtain the sample configuration information stored in the API database, and perform field matching between the target customer instruction and the sample configuration information; S3. When the target customer instruction and the sample configuration information have a field match, determine the first matching field, extract the target change field corresponding to the first matching field from the target customer instruction, match the target change field with the sample change field stored in the API database, and determine the successfully matched target change field as a valid change field. S4. Obtain the initial configuration information stored in the API database that corresponds to the first matching field, and switch the setting status of the corresponding configuration option in the initial configuration information between the enabled state and the disabled state according to the valid change field. S5. When there is no field match between the target customer instruction and the sample configuration information, obtain the sample function information stored in the API database, perform field matching between the target customer instruction and the sample function information, and determine the second matching field when there is a field match. S6. Generate independent configuration options based on the second matching field, add the independent configuration options to the sample configuration information and the initial configuration information respectively, and set the newly added independent configuration options in the initial configuration information to the enabled state.

2. The method according to claim 1, characterized in that, The process of obtaining the target customer's instructions includes: Establish a communication connection between the API client application server and the client client; The client receives the selection operation of the customer for the configuration tag through the client service terminal, and generates the target customer instruction carrying the configuration change information based on the selected configuration tag. The client service terminal sends the target customer instruction to the API client application server to trigger API configuration processing for the corresponding customer.

3. The method according to claim 1, characterized in that, The step of matching the target customer instruction with the sample configuration information includes: Read pre-stored sample configuration information from the API database. The sample configuration information includes configuration fields corresponding to existing configuration options in the API platform. The configuration change information carried by the target customer instruction is matched with the configuration fields one by one; When there is a field in the configuration change information that matches the configuration field, the matching field is determined as the first matching field, and the existing configuration option pointed to by the target customer instruction is determined based on the first matching field. Extract the target change field from the target customer instruction to indicate the change in the setting status of the existing configuration options.

4. The method according to claim 3, characterized in that, The process for determining the valid change fields includes: Read the pre-stored sample change field from the API database. The sample change field is used to characterize the setting status change content corresponding to the configuration option. The target change fields extracted from the target customer's instruction are matched with the sample change fields. When the target change field matches the sample change field, the matching target change field is determined as a valid change field, and a correspondence is established between the valid change field and the existing configuration option pointed to by the first matching field.

5. The method according to claim 4, characterized in that, The step of changing the setting status in the initial configuration information according to the valid change field includes: Based on the first matching field, the initial configuration information of the corresponding customer is obtained from the API database, and the configuration options to be changed corresponding to the first matching field are determined in the initial configuration information; Determine the target setting status corresponding to the configuration option to be changed based on the valid change fields; Change the current setting status of the configuration option to be changed to the target setting status; The current setting state and the target setting state are respectively a checked state and an unchecked state. The checked state is used to indicate that the configuration option to be changed is enabled, and the unchecked state is used to indicate that the configuration option to be changed is not enabled.

6. The method according to claim 1, characterized in that, When the target customer instruction does not have a field match with the sample configuration information, the process of determining the second matching field includes: Read pre-stored sample function information from the API database. The sample function information includes function fields corresponding to the functions that the API platform can provide. The configuration change information carried by the target customer instruction is matched with the function fields. When there is a field in the configuration change information that matches the functional field, the matching functional field is determined as the second matching field; The function to be added corresponding to the target customer instruction is determined based on the second matching field, and the initial configuration information of the corresponding customer is obtained.

7. The method according to claim 6, characterized in that, The step of generating and adding independent configuration options based on the second matching field includes: The configuration options corresponding to the function to be added are determined based on the second matching field; Add the configuration option to the sample configuration information, so that the added configuration option becomes a configuration field in the sample configuration information; The configuration options are synchronously added to the initial configuration information of the corresponding customer, so as to form independent configuration options corresponding to the functions to be added in the initial configuration information; The setting status of the newly added independent configuration option in the initial configuration information is set to the checked state to enable the function to be added.

8. The method according to claim 6, characterized in that, When the target customer instruction does not have a field match with the sample function information, the following is also included: Send the target customer instruction and a second error message indicating that the function field matching failed to be sent to the API console; The API console responds to manual processing operations to determine the second matching field corresponding to the target customer's instruction, and receives the second matching field returned by the API console; Based on the returned second matching field, the corresponding configuration option is determined, and the configuration option is added to the sample configuration information and the corresponding customer's initial configuration information, respectively. The setting status of the newly added configuration option in the initial configuration information is determined to be the checked status.

9. The method according to claim 3, characterized in that, The process of changing existing configuration options also includes: If a valid change field cannot be determined from the target customer instruction based on the first matching field, the target customer instruction and a first error message are sent to the API console; or, When a target change field is extracted from the target customer instruction, but the target change field does not match the sample change field, the target customer instruction and the third error message are sent to the API console. The API console responds to manual processing operations to determine the valid change fields and receives the valid change fields returned by the API console. The target setting state of the corresponding configuration option is determined based on the returned valid change fields, and the current setting state of the configuration option in the initial configuration information of the corresponding customer is changed to the target setting state.

10. A granular extension system for API configuration options, characterized in that, The method applied to any one of claims 1-9 includes: The instruction sending module is used to obtain the target customer instruction sent by the API client application server, and the target customer instruction carries configuration change information. The field matching module is used to obtain sample configuration information stored in the API database and perform field matching between the target customer instruction and the sample configuration information; The valid field determination module is used to determine a first matching field when the target customer instruction and the sample configuration information have a field match, extract the target change field corresponding to the first matching field from the target customer instruction, match the target change field with the sample change fields stored in the API database, and determine the successfully matched target change field as a valid change field; The state switching module is used to obtain the initial configuration information stored in the API database that corresponds to the first matching field, and switch the setting state of the corresponding configuration option in the initial configuration information between the enabled state and the disabled state according to the valid change field. The instruction matching module is used to obtain sample function information stored in the API database when there is no field match between the target customer instruction and the sample configuration information, perform field matching between the target customer instruction and the sample function information, and determine the second matching field when there is a field match. The configuration update module is used to generate independent configuration options based on the second matching field, add the independent configuration options to the sample configuration information and the initial configuration information respectively, and set the newly added independent configuration options in the initial configuration information to the enabled state.

Images