API protocol adaptation method and system, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an API (Application Program Interface) protocol adaptation method and system, electronic equipment and a storage medium, and relates to the technical field of computers. According to the method, semantic understanding can be carried out on a description file of a first API protocol on a client side and a description file of a second API protocol on an API server side through a generative agent; the first API protocol is used for identifying the protocol content difference of the first API protocol compared with the second API protocol, and automatically generating a corresponding adaptation layer code according to the identified protocol content difference; and an adaptation layer code generated by the generative agent is loaded to the gateway, so that the gateway converts the API request sent by the client into a format adaptive to the API server by means of the adaptation layer code. Through application of the embodiment of the invention, the problem of compatibility between the server and the API server can be solved, meanwhile, the manpower cost and the time cost consumed during API protocol conversion are saved, and the adaptation period between different API protocols is shortened.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to API protocol adaptation methods, systems, electronic devices, and storage media. Background Technology

[0002] In scenarios where clients call API (Application Programming Interface) services, compatibility issues often arise when clients call API services because the protocols used by the client and the API server are different or the versions of the protocols used are different.

[0003] To overcome the aforementioned compatibility issues, protocol conversion is typically performed on the API protocol used by the client. Traditional protocol conversion solutions rely heavily on manual intervention; for example, when field types or formats change, the adaptation logic must be manually modified one by one. Such manual operations are not only time-consuming and labor-intensive with long adaptation cycles, but are also highly susceptible to compatibility errors due to oversights, leading to server call chain interruptions or data anomalies. Summary of the Invention

[0004] The purpose of this application is to provide an API protocol adaptation method, system, electronic device, and storage medium to save the manpower and time costs required for API protocol conversion and shorten the adaptation cycle between different API protocols. The specific technical solution is as follows: In a first aspect, embodiments of this application provide an API protocol adaptation method, including: Obtain a first description file for a first API protocol and a second description file for a second API protocol; the first API protocol is applied in the client, and the second API protocol is applied in the API server; invoke a pre-trained generative agent to perform semantic understanding on the first and second description files to identify protocol content differences between the first and second API protocols; protocol content differences include field-level differences and / or port-level differences; based on the semantic understanding results of the identified protocol content differences, the generative agent generates corresponding adaptation layer code for the protocol content differences; the adaptation layer code is used to: convert the protocol content differences existing in the API requests applying the first API protocol so that the converted API requests are adapted to the second API protocol; load the adaptation layer code into the gateway so that the gateway converts the API requests sent by the client into a format adapted to the API server based on the adaptation layer code.

[0005] Secondly, embodiments of this application provide an API protocol adaptation system, including a client, a gateway, and an API server: The client is used to: send API requests to the gateway based on a first API protocol; the gateway is used to: obtain a first description file of the first API protocol and a second description file of the second API protocol; invoke a pre-trained generative agent to perform semantic understanding on the first and second description files to identify protocol content differences between the first and second API protocols; the protocol content differences include field-level differences and / or port-level differences; the generative agent generates corresponding adaptation layer code based on the semantic understanding results of the identified protocol content differences; the adaptation layer code is used to: convert the protocol content differences in the API requests using the first API protocol so that the converted API requests are adapted to the second API protocol; load the adaptation layer code generated by the generative agent to convert the API requests sent by the client based on the adaptation layer code, and send the converted API requests to the API server; the API server is used to: receive the API requests adapted to the second API protocol after conversion by the gateway, and perform processing on the received API requests.

[0006] Thirdly, embodiments of this application provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; the memory is used to store computer programs; and the processor is used to implement the API protocol adaptation method of the first aspect when executing the program stored in the memory.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the API protocol adaptation method described in the first aspect.

[0008] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to execute the API protocol adaptation method described in the first aspect.

[0009] Beneficial effects of the embodiments in this application: The API protocol adaptation method, system, electronic device, and storage medium provided in this application overcome the drawbacks of traditional manual API protocol methods by leveraging the semantic understanding and code generation capabilities of a pre-trained generative agent to achieve API protocol conversion between the client and the API server. Specifically, the generative agent can semantically understand the description files of the first API protocol on the client side and the second API protocol on the API server side, autonomously identify the differences in protocol content between the first and second API protocols, and autonomously generate corresponding adaptation layer code for the identified differences. By loading the adaptation layer code generated by the generative agent onto the gateway, the gateway can use this code to convert the API requests sent by the client into a format compatible with the API server, thus overcoming the protocol incompatibility problem between the client and the API server.

[0010] As can be seen from the above, this application's embodiments, by applying a generative intelligent agent with semantic understanding and code generation capabilities to API service call scenarios, can automatically understand the differences between the client-side API protocol and the API server-side API protocol, generate adaptation layer code, and automatically convert API requests based on the adaptation layer code. Compared with traditional API protocol conversion methods based on manual intervention, this approach can overcome compatibility issues between the server and the API server, save the manpower and time costs required for API protocol conversion, and shorten the adaptation cycle between different API protocols.

[0011] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0012] 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 only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0013] Figure 1 A flowchart illustrating the API protocol adaptation method provided in this application embodiment; Figure 2 A schematic diagram illustrating the training process of a generative agent provided in an embodiment of this application; Figure 3 This is a first schematic diagram illustrating the process by which a gateway, according to an embodiment of this application, processes an API request issued by a client. Figure 4This is a second schematic diagram illustrating the processing procedure of an API request issued by a client by a gateway provided in an embodiment of this application. Figure 5 A schematic diagram of the API protocol adaptation system provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] 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 embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0015] In scenarios where clients call API services, compatibility issues often arise when clients call API services because the protocols used by the client and the API server are different or the versions of the protocols used are different.

[0016] To overcome the aforementioned compatibility issues, protocol conversion is typically performed on the API protocol used by the client. Traditional protocol conversion solutions rely heavily on manual intervention; for example, when field types or formats change, the adaptation logic must be manually modified one by one. Such manual operations are not only time-consuming and labor-intensive with long adaptation cycles, but are also highly susceptible to compatibility errors due to oversights, leading to server call chain interruptions or data anomalies.

[0017] This application provides an API protocol adaptation method, see [link to relevant documentation]. Figure 1 The method specifically includes the following steps: Step S101: Obtain the first description file of the first API protocol and the second description file of the second API protocol; the first API protocol is applied in the client and the second API protocol is applied in the API server.

[0018] For example, an API protocol description file may include an API protocol document. An API protocol document is a technical document used to describe basic information such as the interaction rules, technical specifications, and usage methods of the API protocol. In one example, the API protocol document obtained in this application example may be a structured description file such as Swagger (an API documentation generation tool), OpenAPI (an API description protocol), or YAML (a lightweight data serialization format).

[0019] Step S102: Invoke the pre-trained generative agent to perform semantic understanding on the first description file and the second description file to identify the differences in protocol content between the first API protocol and the second API protocol.

[0020] Specifically, generative agents can perform semantic understanding on the first and second description files to extract semantic information such as field names, field data types, endpoint paths, and request / response structures, and identify the differences in protocol content between the first and second API protocols.

[0021] In this embodiment, the protocol content differences to be identified can include both field-level differences and port-level differences. Both field-level and port-level differences can be further subdivided into multiple difference types. This embodiment does not limit the specific difference types included in field-level and port-level differences; these can be set according to actual needs.

[0022] For example, field-level differences can be encompassed by one or more difference types: Missing fields: This refers to fields in the second API protocol that do not have a corresponding mapping in the first API protocol.

[0023] Field splitting refers to the process where a field in the first API protocol is split into multiple new fields in the second API protocol according to business rules. These new fields have complementary semantics, and the value of the first field is determined by the values ​​of the multiple new fields. For example, the price field in the first API protocol is split into a unit_price field (floating-point) and a tax field (percentage) in the second API protocol, and the split unit_price field and tax field are associated with the same endpoint / v2 / calculate.

[0024] Field merging: refers to the combination of multiple fields in the first API protocol into a new field in the second API protocol according to business rules. These multiple fields have complementary semantics, and the value of the new field is determined by the values ​​of the multiple fields.

[0025] Field renaming refers to a change in the name of a field while maintaining the same meaning. For example, the user_id field in the first API protocol is renamed to user_identifier in the second API protocol.

[0026] Data type change: This refers to a situation where the meaning of a field remains the same, but the data type of the data stored in the field changes. For example, the data type of the user_id field is int (integer) in the first API protocol, but changes to string (string) in the second API protocol.

[0027] Port-level differences can include one or more of the following difference types: Port path change: This refers to a change in the access path of the API port used to implement the same business logic. For example, the path / v1 / user / id used to request user information in the first API protocol changes to / v2 / user / uuid in the second API protocol.

[0028] Step S103: Based on the semantic understanding of the identified protocol content differences, the generative agent generates corresponding adaptation layer code for the protocol content differences; the adaptation layer code is used to: convert the protocol content differences existing in the API request applying the first API protocol so that the converted API request is adapted to the second API protocol.

[0029] As mentioned in the previous explanation of step S102, by performing semantic understanding on the first and second description files, the generative agent can identify various protocol content differences between the first and second API protocols. Specifically, the generative agent can identify the type and content of each protocol content difference. For example, the generative agent might identify the following protocol content differences between the first and second API protocols: Difference 1, the difference type is field splitting, and the difference content is splitting the price field into the unit_price field and the tax field; Difference 2, the difference type is field renaming, and the difference content is renaming the user_id field to the user_identifier field; ...

[0030] In this step, the adaptation layer code generated by the generative agent can specifically include code snippets generated for each identified protocol content difference. The code snippet generated for a protocol content difference is used to transform the portion of the API request applying the first API protocol that contains that protocol difference, so that the transformed portion is adapted to the second API protocol. Specifically, for a protocol content difference, the generative agent can generate corresponding adaptation layer code according to the type and content of the difference, following a transformation strategy for that protocol content difference. For example, the conversion strategy for field splitting types could be: mapping the field in the first API protocol to its corresponding split field in the second API protocol (this requires the generative model to learn the conversion relationship between field values ​​before and after splitting based on semantic understanding capabilities when performing semantic understanding on the first and second description files); the conversion strategy for port path changes could be: redirecting the port path in the first API protocol to the corresponding port path in the second API protocol; the conversion strategy for data type changes could be: converting the data type of the field value in the first API protocol to its data type in the second API protocol, for example, converting the integer in the first API protocol to the UUID (Universally Unique Identifier) ​​in the second API protocol; ...

[0031] In one example, regarding the protocol content difference where the `price` field in the first API protocol is split into the `unit_price` field and the `tax` field in the second API protocol, the code snippet generated for this protocol content difference is specifically used to split the `price` field in the first API protocol into the `unit_price` field and the `tax` field. For example, this code snippet could be: double unitPrice = oldRequest.getDouble("price") (1 - taxRate); newRequest.set("unit_price", unitPrice); newRequest.set("tax", taxRate 100 + "%"); In one possible implementation of this application, an existing generative AI (Artificial Intelligence) model with semantic understanding and code generation capabilities can be obtained first. Then, this generative AI model is fine-tuned (i.e., further trained) to enable it to understand API protocols and generate adaptation layer code. The fine-tuned generative AI model is then used as the generative agent applied in step S102. For example, the generative agent required in this embodiment can be obtained by fine-tuning a Codex variant (an AI programming tool) of the Transformer (a model architecture) architecture.

[0032] In one example, the process of fine-tuning a generative AI model can be as follows: Figure 2 As shown. The first step is the training data construction stage. Specifically, we first need to obtain the API protocol description document, then construct training data based on the API protocol description document, and finally generate training triples based on the constructed training data.

[0033] In the training data construction phase, description documents of various types and versions of API protocols can be obtained first, and multiple API protocol groups can be constructed. A set of triplet data is then constructed based on each API protocol group to obtain a large amount of triplet data for model training. Specifically, an API protocol group includes two different API protocols. In this embodiment, for an API protocol group, the two API protocols within the group can be designated as the first protocol and the second protocol, respectively. Based on the description documents of the first and second protocols, the differences in protocol content between the first and second protocols are identified. Based on these differences, conversion code (equivalent to adaptation layer code, containing code snippets for converting the various differences in protocol content within the first protocol) is written to convert the first protocol to the second protocol. The description files of the first and second protocols, along with the written conversion code, are used as the triplet data constructed for that API protocol group.

[0034] After completing the training data construction phase, the next step is model training. Specifically, the model to be trained (i.e., the pre-acquired generative AI model) can be trained based on the large number of triplet data constructed in the training data construction phase. This allows the model to perform multi-task learning based on these triplet data, thereby acquiring the ability to recognize differences (i.e., the model's ability to identify the differences in protocol content between two different API protocol description files) and the ability to generate code (i.e., the model's ability to generate corresponding adaptation layer code for two different API protocol description files). After training is completed, a pre-trained conversion model (i.e., the generative agent used in steps S102-S103 of this application) can be produced.

[0035] In one example, during the training data construction phase, for a set of API protocols, after identifying the differences in protocol content between the first and second protocols, the difference type labels and content of each difference can be further listed. For each API protocol set, a four-tuple dataset is constructed, containing the description file for the first protocol, the description file for the second protocol, the difference type labels and content of the identified differences in protocol content, and the conversion code. During the model training phase, the model to be trained is trained based on this constructed four-tuple dataset to enhance the model's ability to understand protocol semantic changes.

[0036] Step S104: Load the adaptation layer code into the gateway so that the gateway can convert the API requests sent by the client into a format adapted to the API server based on the adaptation layer code.

[0037] After the generative agent identifies the differences in protocol content between the first API protocol and the second API protocol, and generates adaptation layer code based on the identified differences, the adaptation layer code generated by the generative agent can be loaded into the gateway.

[0038] As is known to those skilled in the art, in scenarios where a client calls an API service, the client specifically sends an API request to the gateway, which then forwards the API request to the API server for processing. Therefore, in this embodiment, by loading the adaptation layer code into the gateway, the gateway can convert the client's API request based on the first API protocol into the format of the second API protocol used by the API server. Thus, after the gateway forwards the converted API request to the API server, the API server is able to process the received API request, thereby avoiding compatibility issues between the client and the API server caused by differences in their respective API protocols.

[0039] In addition to the long adaptation cycles and susceptibility to oversights mentioned earlier, traditional protocol conversion schemes often suffer from untimely rule updates and high difficulty in updating rules. Specifically, in traditional protocol conversion schemes, to achieve adaptation logic between different API protocols, conversion rules are typically defined separately for the content of the protocol to be converted. However, predefined conversion rules struggle to handle dynamic semantic changes (such as field splitting and merging) and cannot automatically derive complex conversion logic. The rule base requires repeated manual revisions, and in scenarios where multiple protocol versions coexist, the maintenance complexity of the rule base increases exponentially, severely limiting the system's scalability.

[0040] In view of this, in one possible implementation of this application, a pre-trained generative agent can be integrated onto the gateway, and the API protocol adaptation method described above can be executed through "real-time protocol difference parsing + dynamic compilation of adaptation layer code". Specifically, by integrating the pre-trained generative agent onto the gateway, when the gateway receives an API request from a client, it can respond to the current API request by invoking the generative agent in real time to identify the protocol content differences between the first API protocol and the second API protocol used in the API request and generate corresponding adaptation layer code. Then, based on the adaptation layer code, the current API request is converted into a format adapted to the API server and sent to the API server.

[0041] Regarding the implementation method described in the previous paragraph, taking an example where the first API protocol of the client application is the old version and the second API protocol of the API server application is the new version, the gateway's processing procedure for API requests will be illustrated. This processing procedure includes... Figure 3 The following steps are shown in the figure: Step S301: The client sends a legacy API request to the gateway.

[0042] Step S302: In response to the received legacy API request, the gateway invokes AI to resolve the protocol differences.

[0043] The AI ​​here refers to the pre-trained generative intelligent agent mentioned earlier.

[0044] Step S303: The AI ​​integrated within the gateway generates the adaptation layer code.

[0045] Steps S302-S303 specifically refer to the process by which the gateway calls the AI ​​to parse the differences in protocol content between the first API protocol and the second API protocol and generate adaptation layer code. For details, please refer to the previous explanation of steps S102-S103.

[0046] In one example, regarding the "real-time protocol difference parsing + dynamic compilation of adaptation layer code" solution, when the gateway invokes AI to perform protocol difference parsing and generate adaptation layer code for the current API request, to save processing overhead, when invoking AI to perform semantic understanding of the first and second description files, AI can only identify the protocol content differences between the API content involved in the current API request and the second API request, and generate corresponding adaptation layer code only for the API content involved in the current API request, thus obtaining the adaptation layer code corresponding to the current API request. This adaptation layer code is specifically used to convert the current API request into a format compatible with the API server.

[0047] In one example, to ensure that the description file used for protocol difference resolution is the latest version, the gateway can, after receiving the API request from the client, immediately obtain the first description file of the first API protocol of the current API requesting application and the second description file of the second API protocol of the client application, and perform protocol difference resolution based on the obtained first and second description files.

[0048] Step S304: The gateway forwards the new API request to the API server.

[0049] Specifically, the gateway can load the adaptation layer code generated by AI in step S303 into its own runtime environment to convert the old API request received in step S302 into a new API request, and then forward the converted new API request to the API server.

[0050] Step S305: The API server sends a successful response to the gateway for the new API request.

[0051] Step S306: The gateway returns the result to the client.

[0052] This means sending the API server's response to the new API request back to the client.

[0053] For the implementation of the "real-time parsing of protocol differences + dynamic compilation of adaptation layer code" solution, the gateway can refer to the above steps S301-S304 to process each API request received from the client.

[0054] In one example, a lightweight generative AI model can be selected and fine-tuned, and the fine-tuned generative AI model can be integrated into the gateway as the generative agent used in this application, so as to save storage resources and improve the conversion efficiency for API requests.

[0055] Furthermore, dedicated acceleration chips, such as FPGAs (Field-Programmable Gate Arrays), can be integrated into the gateway. These acceleration chips optimize the generative agent's AI inference process (i.e., the process by which the generative agent semantically understands the first and second description files to identify protocol content differences and generates adaptation layer code based on these differences) and code execution process (i.e., the process by which the gateway translates API requests based on the adaptation layer code), thereby improving the efficiency of API request translation.

[0056] In the "real-time protocol difference parsing + dynamic compilation of adaptation layer code" execution method, a generative agent is integrated into the gateway. The gateway responds to client API requests by real-time parsing the differences in protocol content between the API protocol of the current API request application and the API protocol on the API server side. It then dynamically generates corresponding adaptation layer code for these differences, enabling real-time detection of dynamic changes in the client-side API protocol compared to the API server-side API protocol. Compared to solutions that rely on configuring static mapping rules between API protocols for API protocol conversion, this approach overcomes the difficulties and long update cycles associated with static rules, significantly reducing manual maintenance requirements and improving system scalability.

[0057] Of course, in another possible implementation of this application, the API protocol adaptation method described above can also be executed through "offline code generation + online conversion". Specifically, a pre-trained generative agent can be integrated on a server. This generative agent performs semantic understanding on the first and second description files to identify the overall protocol content differences between the first and second API protocols, and generates corresponding adaptation layer code for the identified protocol content differences. Then, the adaptation layer code is loaded into the gateway, allowing the gateway to convert the API requests sent by the client into a format compatible with the API server based on the pre-loaded adaptation layer code. This execution method saves more processing resources and has higher conversion efficiency than the previous "real-time parsing of protocol differences + dynamic compilation of adaptation layer code" method, but it may cause compatibility issues due to the inability to identify the latest updates to the protocol version in a timely manner. In practical applications, the two execution methods can be selected according to the requirements.

[0058] As can be seen from the above description, the API protocol adaptation method provided in this application overcomes the shortcomings of traditional manual API protocol methods by leveraging the semantic understanding and code generation capabilities of a pre-trained generative agent to achieve API protocol conversion between the client and the API server. Specifically, the generative agent can perform semantic understanding on the description files of the first API protocol on the client side and the second API protocol on the API server side, autonomously identify the differences in protocol content between the first and second API protocols, and autonomously generate corresponding adaptation layer code for the identified differences. By loading the adaptation layer code generated by the generative agent onto the gateway, the gateway can use this adaptation layer code to convert the API requests sent by the client into a format compatible with the API server, thus overcoming the protocol incompatibility problem between the client and the API server.

[0059] As can be seen from the above, this application's embodiments, by applying a generative intelligent agent with semantic understanding and code generation capabilities to API service call scenarios, can automatically understand the differences between the client-side API protocol and the API server-side API protocol, generate adaptation layer code, and automatically convert API requests based on the adaptation layer code. Compared with traditional API protocol conversion methods based on manual intervention, this approach can overcome compatibility issues between the server and the API server, save the manpower and time costs required for API protocol conversion, and shorten the adaptation cycle between different API protocols.

[0060] In addition to the long adaptation period mentioned above, traditional protocol conversion solutions also have a drawback: traditional protocol conversion technologies lack real-time detection and repair capabilities, and cannot automatically troubleshoot real-time anomalies such as data type conflicts and interface path failures. They often require manual intervention for troubleshooting, resulting in long fault recovery cycles and seriously affecting system availability.

[0061] In view of this, in one embodiment of this application, anomaly detection and closed-loop self-healing logic for API request conversion results can also be added, which will be described in detail below: In this embodiment of the application, after generating the adaptation layer code according to the aforementioned step S103, in order to avoid conversion anomalies such as type conversion errors and interface path failures caused by the generated adaptation layer code, the adaptation layer code generated by the generative agent can be sandbox verified in a sandbox verification environment first.

[0062] In one example, when performing sandbox verification on the adaptation layer code, a sandbox verification environment can be built based on Docker (an open-source container). By loading the adaptation layer code into the Docker container, the test API request of the application's first API protocol is transformed based on the adaptation layer code. The transformed API request then simulates a call to the API service, thus achieving sandbox verification of the adaptation layer code. Specifically, the execution method mentioned earlier, "real-time protocol difference parsing + dynamic compilation of adaptation layer code," involves loading the adaptation layer code corresponding to the current API request into a Docker container, transforming the current API request using this adaptation layer code, and then simulating a call to the target API service requested by the current API request using the transformed API request.

[0063] For example, when performing sandbox validation on the adapter layer code, it is possible to detect whether the transformation of API requests based on the adapter layer code will cause the following problems: input / output compliance issues, for example, which can be achieved through JSON Schema (a type of validation rule); resource leakage issues, such as unclosed database connections; security policy conflict issues, such as unauthorized access to sensitive fields; ...

[0064] After verifying the adaptation layer code, if the adaptation layer code passes the sandbox verification, that is, if it successfully calls the API service during simulation, the verified adaptation layer code can be loaded into the gateway, and the gateway will actually use the adaptation layer code to transform the API requests sent by the client.

[0065] If the adaptation layer code fails the sandbox verification, that is, when simulating an API service call, an error is returned, such as HTTP400 Bad Request (an error type), then the generative agent can be invoked to analyze the error log of the sandbox verification to determine the cause of the error that caused the adaptation layer code to fail the sandbox verification. Based on the determined error cause, the generative agent determines a repair strategy for the adaptation layer code and generates patch code based on the repair strategy.

[0066] In one example, a generative agent can use a repair strategy for the error type to which the identified error cause belongs as a repair strategy for the adapter layer code under test, and generate patch code based on this repair strategy. For instance, if the failure is caused by the `full_name` field being empty, the repair strategy for the error type of empty field causing splitting failure is to add null value checks. The generative agent can then generate patch code to perform null value checks on the `full_name` field according to this strategy.

[0067] After the generative agent generates patch code for the adaptation layer code that failed sandbox validation, the patch code can be used to repair the failed adaptation layer code. After the repair is completed, the repaired adaptation layer code needs to be sandbox validated again in the sandbox validation environment. If the sandbox validation passes, the validated adaptation layer code can be loaded into the gateway; if the sandbox validation still fails, the generative agent needs to be called again to analyze the cause of the error and generate patch code. The patch code is then used to repair the adaptation layer code that failed sandbox validation, and after the repair is completed, the repaired adaptation layer code is sandbox validated again in the sandbox validation environment. This process is repeated until the adaptation layer code passes sandbox validation or the maximum number of sandbox validation attempts is reached, thus achieving iterative optimization of the adaptation layer code.

[0068] In one example, for the adaptation layer code generated by the generative agent, if the adaptation layer code is repeatedly repaired and sandboxed based on the cycle of sandbox verification failure - repair - sandbox verification again - sandbox verification failure - repair - sandbox verification again... and the adaptation layer code still fails sandbox verification after reaching the maximum number of retries, an alarm message can be issued for the adaptation layer code, prompting relevant personnel to intervene to manually analyze the adaptation layer code and write corresponding patch code, and then repair the adaptation layer code through the manually written patch code.

[0069] In this embodiment, a sandbox verification environment is used to perform sandbox verification on the adaptation layer code generated by the generative agent. If the adaptation layer code fails the sandbox verification, the generative agent is used to perform iterative repair, thus achieving a closed-loop repair mechanism for the adaptation layer code. This avoids API service call failures due to conversion logic errors in the generated adaptation layer code and significantly reduces the manual intervention required for fault repair, saving labor costs.

[0070] In one embodiment of this application, for the execution method of "real-time parsing of protocol differences + dynamic compilation of adaptation layer code", if the adaptation layer code that failed the sandbox verification passes the sandbox verification after being repaired based on a patch, then repair cases can be constructed based on the adaptation layer code that failed the sandbox verification, the error that caused the adaptation layer code to fail the sandbox verification, the repair strategy and patch code applied when repairing the adaptation layer code, and the repaired adaptation layer code. After constructing the repair cases, the constructed repair cases can be added to a pre-configured repair case library to update the repair case library, and the generative agent can be optimized and trained based on the updated repair case library.

[0071] The model fine-tuning algorithm used in the optimization training of generative agents based on the repair case library can be selected according to actual needs, and the embodiments of this application do not limit it.

[0072] In addition to the latest remediation cases, the remediation case library also includes remediation cases built during the previous operation of the gateway, based on the remediation adaptation layer code that has been verified through sandboxing in its operational history.

[0073] In one example, to ensure that the generative agent has the ability to repair adaptation layer code from the initial stage of gateway operation, a repair case sample set can be established before the generative agent is actually integrated into the gateway. This sample set is then incorporated into a repair case library, and the generative agent is trained based on this library. Finally, the trained generative agent is integrated into the gateway. The repair case sample set can include a large number of repair case samples. Each repair case sample includes pre-collected abnormal adaptation layer code (when a sample API request is transformed based on the abnormal adaptation layer code, an exception will be returned when calling the API server's service based on the transformed API request), the error reason that caused the abnormal adaptation layer code to return an exception, the repair strategy and patch code applied when repairing the abnormal adaptation layer code, and successfully repaired abnormal adaptation layer code (when a sample API request is transformed based on the successfully repaired abnormal adaptation layer code, the transformed API request can successfully call the API server's service).

[0074] In another example, the mapping relationship between error types and repair strategies can be pre-configured in the gateway. In the early stages of the generative agent's operation, for the adaptation layer code that fails the sandbox verification, the repair strategy corresponding to the error type of the error that caused the adaptation layer code to fail the sandbox verification is determined according to the mapping relationship. Based on the repair strategy, the corresponding patch code is generated. After a sufficient number of successfully repaired cases are accumulated and included in the repair case library during operation, the generative agent is trained based on the repair case library, so that the generative agent can autonomously analyze the repair strategy and generate patch code without relying on the mapping relationship.

[0075] In this embodiment of the application, by accumulating repair cases during actual operation and optimizing the generative agent based on the repair cases, the generative agent's ability to generate appropriate patch code for different error causes can be improved, the repair performance of the generative agent for the adaptation layer code can be improved, and it can adaptively solve unforeseen compatibility problems by learning from historical repair cases.

[0076] As mentioned in the previous explanation of step S103, the generative agent can identify the types and contents of the differences between the first API protocol and the second API protocol. In one embodiment of this application, after identifying the differences between the first API protocol and the second API protocol by calling the generative agent according to the aforementioned step S102, the conflict level of the identified differences can be determined based on the types of differences identified by the generative agent and a predefined conflict grading rule, and the processing priority for each difference can be determined based on the conflict level.

[0077] The conflict classification rule defines the mapping relationship between difference types and conflict levels. Based on this rule, differences in protocol content can be categorized into specific conflict levels. This application does not limit the specific content of the conflict classification rule; it can be set according to actual needs. For example, the conflict levels can be set to three levels: high-risk, medium-risk, and low-risk. Difference types for high-risk conflicts include: missing required fields, and / or, incompatible security policies; difference types for medium-risk conflicts include: changes to optional data types of fields; and difference types for low-risk conflicts include: updated field description text.

[0078] If the processing priority for each protocol content is determined based on the conflict level of the differences in the content, it can also be set according to actual needs. For example, in the example provided in the previous paragraph, the processing priority for protocol content differences with high-risk conflicts can be set higher than that for protocol content differences with medium-risk conflicts, and the processing priority for protocol content differences with medium-risk conflicts can be set higher than that for protocol content differences with low-risk conflicts.

[0079] After determining the processing priorities for the differences in the various protocol contents, the generative agent can process the identified differences sequentially according to the determined priorities. In other words, the generative agent can first generate adaptation layer code for the highest priority protocol content difference and perform sandbox verification on it; after the adaptation layer code passes the sandbox verification, it will then generate adaptation layer code for the next highest priority protocol content difference and perform sandbox verification on it, and so on.

[0080] Furthermore, for certain protocol content differences, generative agents may determine that a particular protocol content difference does not need to be processed based on its type and content. In such cases, adaptation layer code need not be generated for that difference, and no subsequent conversion is required. For example, a protocol content difference whose type is a change in field description text will not have a real impact on the API request's execution mechanism and therefore does not need to be processed.

[0081] Taking the execution method of "real-time parsing of protocol differences + dynamic compilation of adaptation layer code" as an example, if the generative agent identifies three differences in protocol content between the current first API request and the second API protocol, denoted as difference 1, difference 2, and difference 3 respectively, and determines that difference 1 has a higher priority than difference 2, and difference 2 has a higher priority than difference 3 according to the conflict classification rules, then the generative agent can first generate adaptation layer code 1 for difference 1 and perform sandbox verification on it; after adaptation layer code 1 passes sandbox verification, it can then generate adaptation layer code 2 for difference 2 and perform sandbox verification on it; after adaptation layer code 2 passes sandbox verification, it can then generate adaptation layer code 3 for difference 3 and perform sandbox verification on it.

[0082] In this embodiment of the application, by determining the processing priority of each protocol content difference according to the conflict level, and designing a generative agent to process each protocol content difference in sequence according to the processing priority, it can be ensured that high-risk protocol content differences are processed first and responded to in a timely manner, thereby achieving the optimal allocation of processing resources.

[0083] In one embodiment of this application, after performing semantic understanding on the first description file and the second description file, the generative agent can construct a protocol knowledge graph between the first API protocol and the second API protocol based on the semantic understanding results, and store the semantic understanding results in the form of a protocol knowledge graph.

[0084] The protocol knowledge graph consists of nodes and edges. Nodes represent entities within the API protocol, such as ports, fields, and the data types of fields. Edges represent relationships between nodes, such as the dependency relationship between a field and its endpoint, the parent-child nesting relationship between different fields, and the definition relationship between a field and its data type. In this embodiment, the nodes of the protocol knowledge graph can be divided into two categories: first-class nodes representing entities (ports, fields, data types) within the first API protocol, and second-class nodes representing entities within the second API protocol. The edges of the protocol knowledge graph can also be divided into two categories: first-class edges representing relationships between nodes within the same API protocol (i.e., relationships between different first-class nodes or relationships between different second-class nodes), and second-class edges representing mapping relationships between first-class nodes and second-class nodes (for example, if the user_id field in the first API protocol is renamed to the user_identifier field in the second API protocol, then there is an edge representing the renaming relationship between the first-class node representing the user_id field and the second-class node representing the user_identifier field in the protocol knowledge graph; if the price field in the first API protocol is split into the unit_price field and the tax field in the second API protocol, then there is an edge representing the splitting relationship between the first-class node representing the price field and the second-class node representing the unit_price field, and between the first-class node representing the price field and the second-class node representing the tax field).

[0085] In one embodiment of this application, the aforementioned protocol knowledge graph can be further converted into graph structure data for storage, as detailed below: In this application example, after constructing the protocol knowledge graph between the first API protocol and the second API protocol, the embedding vector of each node in the protocol knowledge graph can be determined based on the graph embedding algorithm, so as to convert the protocol knowledge graph into graph structure data.

[0086] Specifically, when determining the embedding vector of a node based on the graph embedding algorithm, the attribute information of the node itself, as well as the attribute information of the edges connected to the node (such as the nesting relationship between the user_id field and the user_profile field in the first API protocol, and the renaming relationship between the user_id field in the first API protocol and the user_identifier field in the second API protocol), can all be integrated into the embedding vector. Thus, the transformed graph structure data can reflect the information of each node and edge in the original protocol knowledge graph.

[0087] This application does not limit the specific graph embedding algorithm used; the algorithm can be selected according to actual needs. In one example, the GraphSAGE algorithm (a graph embedding algorithm) can be used.

[0088] In one possible implementation of this application, an API protocol description file, in addition to the API protocol document including the API protocol, may further include historical request logs of the API protocol. These historical request logs may include request parameters, response structures, request error types, etc., of the API protocol. Besides assisting the generative agent in semantically understanding the protocol content of the API protocol to more accurately identify differences in protocol content between the first API protocol and the second API protocol, the historical request logs can also be used to implement the mechanisms in any of the following examples: In one example, in step S102 mentioned above, the generative agent can also determine the key nodes in the first API protocol and the second API protocol based on the semantic understanding of the request logs of the first API protocol and the historical request logs of the second API protocol.

[0089] Key nodes may include one or more of the following: required fields, frequently called fields, and frequently called ports. The frequently called fields are those with a call rate higher than a first preset value in the historical request logs, and the frequently called ports are those with a call rate higher than a second preset value in the historical request logs. The values ​​of the first and second preset values ​​can be set according to actual needs.

[0090] Based on the identification of key nodes in the first and second API protocols, and in the process of converting the protocol knowledge graph into graph structure data using graph embedding algorithms, the embedding vectors of key nodes can be enhanced using a graph attention network (GAT) to improve the representation effect of the identified embedding vectors.

[0091] In one example, in step S102 mentioned above, the generative agent can also determine dynamic data such as error distribution data of fields in the first API protocol and the second API protocol based on the semantic understanding of the request logs of the first API protocol and the historical request logs of the second API protocol.

[0092] Based on the identified error distribution data of fields within the first and second API protocols, the generative agent can analyze the error distribution data to derive typical error types for each field. Therefore, during the generation of adaptation layer code for a protocol content difference according to step S103, the generative agent can add error verification and handling code for the typical error types of the fields involved in the protocol content difference (including fields within the first and second API protocols) to the adaptation layer code, thus preventing API request exceptions due to field errors. In one example, a mapping relationship between different typical error types and corresponding error verification and handling strategies can be pre-configured. The generative code then determines the error verification and handling strategy corresponding to the current typical error type based on the mapping relationship and generates error verification and handling code accordingly.

[0093] In one embodiment of this application, after converting the protocol knowledge graph into graph structure data represented by embedding vectors, the similarity between the embedding vectors of the first type of nodes and the second type of nodes corresponding to the identified differences in protocol content within the protocol knowledge graph can be determined to quantify the differences in protocol content.

[0094] Specifically, since a protocol content difference represents the difference between the content in the first API protocol and the content in the second API protocol, a protocol content difference has corresponding first-type nodes and corresponding second-type nodes in the protocol knowledge graph. For example, for the protocol content difference of renaming the user_id field in the first API protocol to the user_identifier field in the second API protocol, it corresponds to a first-type node representing the user_id field and a second-type node representing the user_identifier field in the knowledge graph; for the protocol content difference of splitting the price field in the first API protocol into the unit_price field and the tax field in the second API protocol, it corresponds to a first-type node representing the price field, a second-type node representing the unit_price field, and a second-type node representing the tax field in the knowledge graph.

[0095] In this embodiment, a protocol content difference can be quantified based on the similarity (exemplarily, cosine similarity) between the embedding vectors of the first and second type nodes corresponding to that difference within the protocol knowledge graph. For example, the quantified value of a protocol content difference can be determined based on the similarity between the embedding vectors of the first and second type nodes corresponding to that difference within the protocol knowledge graph. For instance, when a protocol content difference corresponds to one first type node and one second type node within the protocol knowledge graph, the similarity between the embedding vector of the first type node and the embedding vector of the second type node can be used as the quantified value of the protocol content difference. When a protocol content difference corresponds to more than one first type node and more than one second type node within the protocol knowledge graph, the similarity between the embedding vector of each first type node and the embedding vector of each second type node can be cross-calculated, and the quantified value of the protocol content difference can be determined based on the determined similarities, such as using the average of the determined similarities as the quantified value of the protocol content difference.

[0096] In this embodiment, after quantifying the differences in protocol content between the first API protocol and the second API protocol, the processing priority for each difference can be determined based on the conflict level of each difference and the quantification results. Subsequently, as described above, the generative agent can process the identified differences in protocol content sequentially according to the determined processing priority.

[0097] This application does not limit the specific implementation method of determining processing priority based on conflict level and quantification results. In one example, based on the determination that the priority of protocol content differences with high conflict level is higher than that of protocol content differences with low conflict level, for each protocol content difference of the same conflict level, the processing priority of protocol content differences with high quantification value is determined to be higher than that of protocol content differences with low quantification value.

[0098] In one possible implementation of this application, a protocol parsing module, a difference comparison module, a code generation module, a sandbox verification module, and a hardware acceleration module can be configured in the gateway to implement the API protocol adaptation method provided in the above embodiments of this application. For ease of understanding, the functions of each module are first described: The protocol parsing module can include functions such as semantic parsing and knowledge graph construction.

[0099] Semantic parsing involves invoking a generative agent to parse the description files of the first and second API protocols, extracting semantic information such as field names, data types, endpoint paths, and request / response structures, and identifying differences in protocol content between the first and second API protocols. Specifically, the input data for the generative agent can include the API protocol document and historical request logs of the first API protocol, as well as the API protocol document and historical request logs of the second API protocol.

[0100] Knowledge graph construction involves building a protocol knowledge graph based on the semantic understanding results of generative agents. In one example, when constructing the protocol knowledge graph, dynamic data such as the actual usage frequency and error distribution of fields in the first and second API protocols can be added as node attribute information based on the analysis results of historical request logs by the generative agent.

[0101] The functions of the difference comparison module can include: graph embedding generation, difference quantification, and conflict classification.

[0102] Graph embedding generation converts the protocol knowledge graph generated by the protocol parsing module into graph-structured data.

[0103] Difference quantification and conflict classification involve calculating the cosine similarity of the embedding vectors of the first and second type nodes in the knowledge protocol graph for the identified differences in protocol content between the first and second API protocols. This quantifies the identified differences, such as type conflicts and path changes, generating a difference matrix. Based on predefined conflict classification rules and the quantification results for each protocol content difference, the processing priority for each difference is determined, and a difference priority list is output.

[0104] Specifically, the difference matrix can list each difference entry for the content of the first API protocol compared to the second API protocol. Each difference entry can include: the type and content of the difference, as well as the quantified value of that difference.

[0105] The difference priority list can include the processing order for differences in protocol content within the difference matrix, determined by processing priority. Specifically, the difference priority list guides the dynamic code generation module in subsequently processing requests according to conflict level.

[0106] The code generation module can include code generation functionality.

[0107] Specifically, the code generation module can generate corresponding adaptation layer code based on the difference matrix provided by the difference comparison module, targeting the differences in the protocol content listed therein. The adaptation layer code can cover logic such as field conversion, path redirection, and error handling.

[0108] In one example, the adapter layer code could be written in Java (a programming language).

[0109] The functionality of the sandbox validation module can include sandbox validation.

[0110] Sandbox verification involves performing sandbox verification on the adaptation layer code generated by the code generation module within a sandbox verification environment.

[0111] The code generation module can also include closed-loop repair functionality.

[0112] Closed-loop repair means that when the adaptation layer code fails the sandbox verification, a generative agent is invoked to analyze the error log, generate patch code for the adaptation layer code that failed the sandbox verification, repair the adaptation layer code that failed the sandbox verification based on the patch code, and then feed the repaired adaptation layer code back to the sandbox verification module so that it can re-enter the sandbox verification until the adaptation layer code passes the sandbox verification or the maximum number of retries is reached.

[0113] The hardware acceleration module integrates an acceleration chip to optimize the AI ​​inference and code execution process.

[0114] Based on the above modules, taking the client using the old API protocol and the API server using the new API protocol as an example, the gateway's processing flow for API requests sent by the client is as follows: Figure 4 As shown, see Figure 4 The processing flow includes the following steps: Step S401: The client sends a request for the legacy API.

[0115] Step S402: The protocol parsing module calls the AI ​​model to parse the semantics.

[0116] The AI ​​model is the generative intelligent agent mentioned earlier. The protocol generation module can analyze the description files of the first API protocol and the second API protocol by calling the AI ​​model, identify the differences in protocol content between the first API protocol and the second API protocol, and construct a protocol knowledge graph between the first API protocol and the second API protocol.

[0117] The process of calling the AI ​​model to parse semantics can be executed by calling the acceleration chip through the hardware acceleration module.

[0118] Step S403: The hardware acceleration module returns the protocol knowledge graph to the protocol parsing module.

[0119] Step S404: The protocol parsing module feeds back semantic data to the difference comparison module.

[0120] This means feeding back the protocol knowledge graph to the difference comparison module.

[0121] Step S405: The difference comparison module requests embedded calculation.

[0122] Specifically, the difference comparison module requests the hardware acceleration module to determine the embedding vectors of each node in the protocol knowledge graph based on a graph embedding algorithm, in order to convert the protocol knowledge graph into graph structure data; and to determine the similarity between the embedding vectors of the first and second type nodes corresponding to the differences in various protocol content within the protocol knowledge graph, in order to quantify the differences in various protocol content and obtain a difference matrix. This processing flow can be executed by the hardware acceleration module calling the acceleration chip.

[0123] Step S406: The hardware acceleration module returns the difference matrix to the difference comparison module.

[0124] Step S407: The difference comparison module sends a difference priority list to the code generation module.

[0125] Specifically, the difference matrix module can determine the conflict level of each protocol content difference according to the conflict classification rules, and determine the priority list by combining the conflict level and quantification value of each protocol content difference. Furthermore, the difference comparison module can send both the difference matrix and the difference priority list to the code generation module.

[0126] Step S408: The code generation module calls the AI ​​model to generate code.

[0127] Specifically, the code generation module calls the AI ​​model to generate adaptation layer code for the legacy API request in step S401.

[0128] Step S409: The code generation module submits code for verification to the sandbox verification module.

[0129] Step S410: The sandbox verification module responds to the code verification submitted by the code generation module and performs verification on the generated adaptation layer code.

[0130] This involves performing sandbox verification on the adaptation layer code generated by the AI ​​model. The sandbox verification process can be executed by the hardware acceleration module calling the acceleration chip.

[0131] Step S411: The hardware acceleration module returns the verification result to the sandbox verification module.

[0132] If the verification result indicates that the adaptation layer code passes the verification, then proceed with the following steps S412-S415: Step S412: The sandbox verification module publishes its code to the gateway.

[0133] This means that the verified adaptation layer code is published to the gateway, enabling the gateway to transform the old API request received in step S401 based on the adaptation layer code, thereby obtaining the new API request. The process of transforming the old API request can be executed by the acceleration chip through the hardware acceleration module.

[0134] Step S413: The gateway forwards the new API request to the API server.

[0135] Step S414: The API server returns a response to the gateway in response to the received new API request.

[0136] Step S415: The gateway returns a new API response to the client.

[0137] If the verification result indicates that the adaptation layer code failed verification, then the following steps S416-S418 will be executed: Step S416: The sandbox verification module notifies the code generation module to trigger the repair process.

[0138] Step S417: In response to the triggering of the repair process, the code generation module calls the AI ​​model to generate patch code for the unverified adaptation layer code.

[0139] After the AI ​​model generates patch code, the code generation module can use this patch code to fix the adaptation layer code that has not passed verification.

[0140] Step S418: The code generation module resubmits the verification to the sandbox verification module.

[0141] In other words, the sandbox verification module is instructed to re-perform sandbox verification for the repaired adaptation layer code. If the repaired adaptation layer code passes verification, the process of steps S412-S415 is executed; if the repaired adaptation layer code fails verification, the process of steps S416-S418 is repeated.

[0142] Compared to traditional API protocol conversion methods, the above API protocol adaptation method can achieve the following beneficial effects: 1. Fully automated real-time protocol conversion was implemented at the gateway layer.

[0143] By embedding lightweight generative agents into the API gateway layer, the semantic differences between the API protocol on the client side and the API protocol on the server side in real time are identified, and adaptation layer code is dynamically generated for the semantic differences. This can replace the traditional static rule engine, thereby breaking through the limitations of predefined rules and realizing AI-driven protocol conversion at the gateway layer, significantly reducing the need for manual maintenance.

[0144] 2. A closed-loop self-repair mechanism has been implemented.

[0145] Based on a sandbox verification environment, real-time detection of anomalies in the conversion logic of AI-generated adaptation layer code triggers AI to iteratively generate patch code to repair the adaptation layer code. The AI ​​model is trained using historical repair cases to achieve greater flexibility, forming a closed-loop process of "detection-repair-verification-iteration." This mechanism enables anomaly repair without manual intervention, reducing fault recovery time from hours to milliseconds, and can adaptively resolve unforeseen compatibility issues.

[0146] 3. It has high real-time performance.

[0147] By integrating hardware acceleration chips and adopting a lightweight model design, extremely low-latency protocol conversion can be achieved, supporting real-time request processing in high-concurrency scenarios.

[0148] 4. It has the capability for cross-protocol hybrid scheduling.

[0149] By using protocol knowledge graphs to uniformly model semantic parsing results, it can support the conversion of heterogeneous protocols such as RESTful (an API design and communication specification), gRPC (an API design and communication specification), and GraphQL (an API design and communication specification), and adapt to the differentiated design of cross-cloud services.

[0150] 5. Improved safety and controllability.

[0151] By performing pre-execution verification of the adapter layer code in a sandbox verification environment, compliance checks and a canary release mechanism for the adapter layer code are implemented, ensuring the safety and reliability of the conversion logic.

[0152] In summary, the API protocol adaptation method provided in this application systematically solves the core problems of traditional solutions, such as high labor costs, rigid rules, delayed repair, and insufficient performance, through the deep integration of generative AI and hardware acceleration technology. It achieves full automation, high real-time performance, and strong compatibility of API protocol conversion, providing disruptive technical support for API governance in fields such as cloud computing, fintech, and the Internet of Things.

[0153] Based on the same inventive concept, this application also provides an API adaptation system, see [link to relevant documentation]. Figure 5 The system includes: client 501, gateway 502, and API server 503.

[0154] Client 501 is used to send API requests to gateway 502 based on the first API protocol.

[0155] Gateway 502 is used to: obtain a first description file of a first API protocol and a second description file of a second API protocol; invoke a pre-trained generative agent to perform semantic understanding on the first and second description files to identify protocol content differences between the first and second API protocols; the protocol content differences include field-level differences and / or port-level differences; the generative agent generates corresponding adaptation layer code based on the semantic understanding results of the identified protocol content differences; the adaptation layer code is used to: convert the protocol content differences in API requests using the first API protocol so that the converted API requests are adapted to the second API protocol; load the adaptation layer code generated by the generative agent to convert the API requests sent by client 501 based on the adaptation layer code, and send the converted API requests to API server 503.

[0156] API server 503 is used to: receive API requests adapted to the second API protocol after being converted by gateway 502, and perform processing on the received API requests.

[0157] For more information on the API protocol adaptation system and its beneficial effects, please refer to the previous description of the API protocol adaptation method implementation, which will not be repeated here.

[0158] In one embodiment of this application, the gateway 502 is further configured to: perform sandbox verification on the adaptation layer code within a sandbox verification environment; when the adaptation layer code passes sandbox verification, execute the step of loading the adaptation layer code generated by the generative agent; when the adaptation layer code fails sandbox verification, call the generative agent to analyze the error log of the sandbox verification to determine the error cause that caused the adaptation layer code to fail sandbox verification; the generative agent determines a repair strategy for the adaptation layer code based on the error cause, and generates patch code based on the repair strategy; repair the adaptation layer code based on the patch code, and return to the step of performing sandbox verification on the adaptation layer code within the sandbox verification environment, until the adaptation layer code passes sandbox verification or the number of sandbox verifications reaches the maximum number of retries.

[0159] In one embodiment of this application, the gateway 502 is further configured to: construct repair cases based on the pre-repair adaptation layer code, the error reasons that caused the pre-repair adaptation layer code to fail the sandbox verification, the repair strategy determined for the pre-repair adaptation layer code, and the patch code used when repairing the adaptation layer code; incorporate the constructed repair cases into a pre-configured repair case library, and optimize the training of the generative agent based on the repair case library.

[0160] In one embodiment of this application, the gateway 502 is further configured to: determine the conflict level of each protocol content difference based on the difference type identified by the generative agent for the differences of each protocol content, combined with a predefined conflict grading rule; the conflict grading rule is used to define the mapping relationship between difference type and conflict level; and determine the processing priority for each protocol content difference based on the conflict level.

[0161] Gateway 502 is specifically used for: generating corresponding adaptation layer code for each protocol content difference according to the processing priority based on the understanding of the identified differences in the content of each protocol by the generative agent; loading the adaptation layer code generated by the generative agent so as to convert the differences in the content of each protocol in the API request according to the processing priority based on the adaptation layer code.

[0162] In one embodiment of this application, the gateway 502 is further configured to: construct a protocol knowledge graph based on the semantic understanding results of the generative agent; the protocol knowledge graph includes nodes and edges, the nodes including: first-type nodes representing ports, fields and data types within a first API protocol, and second-type nodes representing ports, fields and data types within a second API protocol, the edges including: first-type edges representing the association between first-type nodes and the association between second-type nodes, and second-type edges representing the mapping relationship between first-type nodes and second-type nodes; determine the embedding vector of each node in the protocol knowledge graph based on a graph embedding algorithm to convert the protocol knowledge graph into graph structure data; and determine the similarity between the embedding vectors of the first-type nodes and the second-type nodes corresponding to the differences in the content of each protocol in the protocol knowledge graph, so as to quantify the differences in the content of each protocol.

[0163] Gateway 502 is specifically used to: determine the processing priority based on the conflict level of the differences in the content of various protocols and the quantitative results of the differences in the content of various protocols.

[0164] In one embodiment of this application, the first description file includes the API protocol document and historical request logs of the first API protocol, and the second description file includes the API protocol document and historical request logs of the second API protocol. Gateway 502 is specifically used to: invoke a pre-trained generative agent to perform semantic understanding on the first and second description files to identify differences in protocol content between the first and second API protocols, and to determine key nodes in the first and second API protocols; key fields include one or more of the following: required fields, fields with a call rate higher than a first preset value, and endpoints with a call rate higher than a second preset value; determine the embedding vectors of each node in the protocol knowledge graph based on a graph embedding algorithm, and strengthen the embedding vectors of key nodes through an attention mechanism to convert the protocol knowledge graph into graph structure data.

[0165] In one embodiment of this application, the gateway 502 is specifically configured to: respond to a first API request sent by a client, identify the API protocol content involved in the first API request, invoke a generative agent to perform semantic understanding on a first description file and a second description file to identify protocol content differences between the API protocol content and the second API protocol; generate adaptation layer code based on the semantic understanding result of the identified protocol content differences, and obtain adaptation layer code corresponding to the first API request; load the adaptation layer code corresponding to the first API request generated by the generative agent into its own runtime environment to convert the first API request into a format adapted to the API server.

[0166] This application also provides an electronic device, such as... Figure 6 As shown, it includes a processor 601, a communication interface 602, a memory 603, and a communication bus 604, wherein the processor 601, the communication interface 602, and the memory 603 communicate with each other through the communication bus 604. Memory 603 is used to store computer programs; When the processor 601 executes the program stored in the memory 603, it implements the API protocol adaptation method provided in the foregoing embodiments.

[0167] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0168] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0169] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0170] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0171] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above API protocol adaptation methods.

[0172] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the API protocol adaptation methods described above.

[0173] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0174] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0175] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for API protocol adaptation systems, electronic devices, and readable storage media are basically similar to the method embodiments, and therefore the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0176] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. An API protocol adaptation method, characterized in that, include: Obtain the first description file of the first API protocol and the second description file of the second API protocol; The first API protocol is applied in the client, and the second API protocol is applied in the API server; A pre-trained generative agent is invoked to perform semantic understanding on the first description file and the second description file to identify protocol content differences between the first API protocol and the second API protocol; the protocol content differences include field-level differences and / or port-level differences; Based on the semantic understanding of the identified protocol content differences, the generative agent generates corresponding adaptation layer code for the protocol content differences; the adaptation layer code is used to: convert the protocol content differences existing in the API request applying the first API protocol so that the converted API request is adapted to the second API protocol. The adaptation layer code is loaded into the gateway so that the gateway can convert the API requests sent by the client into a format adapted to the API server based on the adaptation layer code.

2. The method according to claim 1, characterized in that, After the generative agent generates corresponding adaptation layer code for the identified protocol content differences based on the semantic understanding results of the identified differences, the method further includes: Perform sandbox verification on the adapter layer code within a sandbox verification environment; Once the adaptation layer code passes the sandbox verification, the step of loading the adaptation layer code into the gateway is executed; When the adaptation layer code fails sandbox verification, the generative agent is invoked to analyze the error logs of the sandbox verification to determine the cause of the error. The generative agent then determines a repair strategy for the adaptation layer code based on the cause of the error and generates patch code based on the repair strategy. The adaptation layer code is repaired based on the patch code, and the process returns to the step of performing sandbox verification on the adaptation layer code in the sandbox verification environment, until the adaptation layer code passes sandbox verification or the maximum number of retries for sandbox verification is reached.

3. The method according to claim 2, characterized in that, After the repaired adapter layer code is verified through a sandbox, the method further includes: Based on the pre-fix adaptation layer code, the error reasons that caused the pre-fix adaptation layer code to fail the sandbox verification, the fix strategy determined for the pre-fix adaptation layer code, and the patch code used to fix the adaptation layer code, a fix case is constructed; The constructed repair cases are incorporated into a pre-configured repair case library, and the generative agent is optimized and trained based on the repair case library.

4. The method according to claim 1, characterized in that, After the pre-trained generative agent is invoked to perform semantic understanding on the first description file and the second description file, the method further includes: Based on the difference types identified by the generative agent for the differences in the content of each protocol, the conflict level of each difference in the content of the protocol is determined in combination with the predefined conflict classification rules; the conflict classification rules are used to define the mapping relationship between difference types and conflict levels. Based on the conflict level, determine the processing priority for the differences in the content of each protocol; The generative agent generates corresponding adaptation layer code based on the semantic understanding of the identified protocol content differences, and loads the adaptation layer code into the gateway so that the gateway can convert the API requests sent by the client into a format adapted to the API server based on the adaptation layer code. This includes: Based on its understanding of the differences in the identified protocol content, the generative agent generates corresponding adaptation layer code for each protocol content difference according to the processing priority. The adaptation layer code generated by the generative agent is loaded into the gateway, so that the gateway, based on the adaptation layer code, sequentially converts the various protocol content differences in the API request according to the processing priority.

5. The method according to claim 4, characterized in that, After the pre-trained generative agent is invoked to perform semantic understanding on the first description file and the second description file, the method further includes: Based on the semantic understanding results of the generative agent, a protocol knowledge graph is constructed; the protocol knowledge graph includes nodes and edges, the nodes include: first-type nodes representing ports, fields and data types within the first API protocol, and second-type nodes representing ports, fields and data types within the second API protocol, the edges include: first-type edges representing the association between first-type nodes and the association between second-type nodes, and second-type edges representing the mapping relationship between first-type nodes and second-type nodes; The embedding vector of each node in the protocol knowledge graph is determined based on the graph embedding algorithm, so as to convert the protocol knowledge graph into graph structure data; The similarity between the embedding vectors of the first and second type nodes corresponding to the differences in the content of each protocol is determined in order to quantify the differences in the content of each protocol. The process of determining the processing priority for differences in the content of each protocol based on the conflict level of each protocol includes: Based on the conflict levels of the differences in the content of each protocol, and combined with the quantitative results of the differences in the content of each protocol, the processing priority is determined.

6. The method according to claim 5, characterized in that, The first description file includes the API protocol document and historical request logs of the first API protocol, and the second description file includes the API protocol document and historical request logs of the second API protocol. The step of invoking a pre-trained generative agent to perform semantic understanding on the first description file and the second description file to identify protocol content differences between the first API protocol and the second API protocol includes: A pre-trained generative agent is invoked to perform semantic understanding on the first description file and the second description file to identify differences in protocol content between the first API protocol and the second API protocol, and to determine key nodes in the first API protocol and the second API protocol; the key fields include one or more of the following: required fields, fields with a call rate higher than a first preset value, and endpoints with a call rate higher than a second preset value; The step of determining the embedding vector of each node in the protocol knowledge graph based on the graph embedding algorithm, in order to convert the protocol knowledge graph into graph structure data, includes: The embedding vectors of each node in the protocol knowledge graph are determined based on the graph embedding algorithm, and the embedding vectors of the key nodes are enhanced through an attention mechanism to convert the protocol knowledge graph into graph structure data.

7. The method according to claim 1, characterized in that, The generative agent is integrated on the gateway. The invocation of the pre-trained generative agent performs semantic understanding on the first description file and the second description file to identify protocol content differences between the first API protocol and the second API protocol, including: The gateway responds to the first API request sent by the client, identifies the API protocol content involved in the first API request, and calls the generative agent to perform semantic understanding on the first description file and the second description file to identify the differences in protocol content between the API protocol content and the second API protocol. The generative agent generates corresponding adaptation layer code based on the semantic understanding results of the identified protocol content differences, including: Based on the semantic understanding of the identified differences in protocol content, the generative agent generates adaptation layer code for the differences in protocol content between the API protocol and the second API protocol, thereby obtaining adaptation layer code corresponding to the first API request. The step of loading the adaptation layer code into the gateway, so that the gateway can convert the API request issued by the client into a format adapted to the API server based on the adaptation layer code, includes: The gateway loads the adaptation layer code generated by the generative agent corresponding to the first API request into its own runtime environment to convert the first API request into a format adapted to the API server.

8. An API protocol adaptation system, characterized in that, This includes clients, gateways, and API servers; The client is used to: send API requests to the gateway based on the first API protocol; The gateway is used to: obtain a first description file of a first API protocol and a second description file of a second API protocol; A pre-trained generative agent is invoked to perform semantic understanding on the first description file and the second description file to identify protocol content differences between the first API protocol and the second API protocol; the protocol content differences include field-level differences and / or port-level differences; Based on the semantic understanding of the identified protocol content differences, the generative agent generates corresponding adaptation layer code for the protocol content differences. The adaptation layer code is used to: convert the protocol content differences existing in the API request applying the first API protocol so that the converted API request is adapted to the second API protocol; load the adaptation layer code generated by the generative agent to convert the API request sent by the client based on the adaptation layer code, and send the converted API request to the API server. The API server is used to: receive API requests adapted to the second API protocol after being converted by the gateway, and to process the received API requests.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-7.

Images