Method and apparatus for managing application programming interface, and device and medium
Patent Information
- Application Number
- PCT/CN2025/079086
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-02-25
- Publication Date
- 2026-09-03
Smart Images
Figure CN2025079086_03092026_PF_FP_ABST
Abstract
Description
Methods, apparatus, devices, and media for managing application programming interfaces Technical Field
[0001] The implementation of this disclosure relates generally to software development, and in particular to methods, apparatus, devices and computer-readable storage media for managing application programming interfaces during the software development process. Background Technology
[0002] In software development, mocking is a method to support testing and development by simulating the behavior of objects or services. Specifically, mocking generates mock code to create virtual objects (e.g., functions or services) to replace real components. These virtual objects can simulate behavior in a real environment, helping developers test without relying on external systems or services. Typically, developers need to manually write mock code to generate it. Although automated code generation tools have been developed, the generated mock code is difficult to understand and adjust, and may not meet testing requirements. Therefore, there is a need for a more accurate and efficient way to manage application programming interfaces (APIs) and generate corresponding mock code. Summary of the Invention
[0003] In a first aspect of this disclosure, a method for managing application programming interfaces (APIs) is provided. In this method, description data of the application's API is obtained. Constraint data is obtained, representing constraints on fields specified by the description data, and the constraint data is represented in natural language. Based on the description data and constraint data, mock code for simulating the functionality of the API is determined using a machine learning model. The mock code is deployed in the application's execution environment to generate a mock interface for simulating the functionality of the application's API.
[0004] In a second aspect of this disclosure, an apparatus for managing application programming interfaces (APIs) is provided. The apparatus includes: a description data acquisition module configured to acquire description data of the API of an application; a constraint data acquisition module configured to acquire constraint data, the constraint data representing constraints on fields specified by the description data, and the constraint data being represented in natural language; a determination module configured to determine, based on the description data and the constraint data, simulation code for simulating the functionality of the API using a machine learning model; and a generation module configured to deploy the simulation code in the execution environment of the application to generate a simulation interface for simulating the functionality of the API of the application.
[0005] In a third aspect of this disclosure, an electronic device is provided. The electronic device includes: at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to a first aspect of this disclosure when executed by the at least one processor.
[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method according to a first aspect of this disclosure.
[0007] In a fifth aspect of this disclosure, a computer program product is provided, including a computer program, wherein the computer program, when executed by a processor, implements the method according to a first aspect of this disclosure.
[0008] It should be understood that the content described in this content section is not intended to limit the key or essential features of the implementation of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description
[0009] In the following detailed description, the above and other features, advantages, and aspects of the various implementations of this disclosure will become more apparent, taken in conjunction with the accompanying drawings. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein:
[0010] Figure 1 shows a block diagram of an application environment according to one implementation of the present disclosure;
[0011] Figure 2 shows a block diagram of an application programming interface for managing some implementations of this disclosure;
[0012] Figure 3 shows a block diagram of the architecture of a module for managing an application programming interface according to some implementations of this disclosure;
[0013] Figure 4 shows a block diagram of deploying emulation code in a gateway environment according to some implementations of this disclosure;
[0014] Figure 5 shows a block diagram of deploying mock code in a web page integration environment according to some implementations of this disclosure;
[0015] Figure 6 shows a block diagram of deploying mock code in a container environment according to some implementations of this disclosure;
[0016] Figure 7 shows a flowchart of a method for managing an application programming interface according to some implementations of this disclosure;
[0017] Figure 8 shows a block diagram of an apparatus for managing an application programming interface according to some implementations of the present disclosure; and
[0018] Figure 9 shows a block diagram of a device that can implement various implementations of the present disclosure. Detailed Implementation
[0019] Implementations of this disclosure will now be described in more detail with reference to the accompanying drawings. While some implementations of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the implementations set forth herein. Rather, these implementations are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and implementations of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.
[0020] In the description of the implementation methods disclosed herein, the term "comprising" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one implementation" or "the implementation" should be understood as "at least one implementation". The term "some implementations" should be understood as "at least some implementations". Other explicit and implicit definitions may also be included below. As used herein, the term "model" can represent the relationships between various data. For example, the aforementioned relationships can be obtained based on various currently known and / or future-developed technical solutions.
[0021] It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.
[0022] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure through appropriate means in accordance with relevant laws and regulations, and user authorization should be obtained.
[0023] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.
[0024] As an optional but non-restrictive implementation, in response to a user's active request, a prompt message can be sent to the user, for example, via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose whether to "agree" or "disagree" to provide personal information to the electronic device.
[0025] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.
[0026] The term "in response to" as used herein refers to a state in which a corresponding event occurs or a condition is satisfied. It will be understood that the timing of subsequent actions performed in response to such event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is met. For example, in some cases, subsequent actions may be performed immediately upon the occurrence of the event or the fulfillment of the condition; while in others, they may be performed some time after the occurrence of the event or the fulfillment of the condition.
[0027] Example Environment
[0028] In software development, mocking techniques support testing and development by simulating the behavior of objects or services. Specifically, mocking techniques can generate mock code to create virtual objects (such as functions or services) and replace real components. These virtual objects can simulate behavior in a real environment, helping developers conduct tests without relying on external systems or services.
[0029] Interface mocking is a crucial step in software development. Figure 1 illustrates an application environment based on some implementations of this disclosure. Figure 1 shows a block diagram 100 of an application environment according to one implementation of this disclosure. As shown in Figure 1, application 110 may include multiple application programming interfaces (APIs), such as API 120, API 122, ..., and API 124. Dependencies may exist between the APIs, and the mocking solution allows developers to simulate dependent objects in a test environment without relying on actual external systems. In this way, developers can develop each API in a relatively independent manner.
[0030] Existing mocking solutions mostly rely on developers manually writing code to simulate API responses. This is not only inefficient but also prone to errors due to human error. With the development of software technology, numerous mocking platforms have emerged, which support configuration-based generative methods to randomly generate content. However, on the one hand, the content generated by these platforms is often difficult to understand, causing considerable trouble for developers during subsequent API debugging and increasing understanding and communication costs. On the other hand, generative methods themselves are difficult to write and require developers to possess high technical skills and complex configuration abilities. For complex API scenarios, the difficulty of writing these methods increases significantly.
[0031] Furthermore, many API fields have format constraints. For example, the "phoneNumber" field requires its content to conform to the specific format of a phone number. However, existing mock platforms struggle to fully utilize the format constraints inherent in these field names and cannot accurately generate mock data that meets both semantic and format requirements. This necessitates significant manual intervention and correction in practical applications, severely impacting the overall efficiency and quality of software development. With the increasing complexity of APIs and the urgent need for rapid iteration and efficient collaboration among development teams, there is a growing demand for a more intelligent and automated mocking solution for API development and testing.
[0032] Overview of Interface Management
[0033] To at least partially address the shortcomings of existing technologies, a method for managing application programming interfaces (APIs) is proposed according to one implementation of this disclosure. In recent years, machine learning model technology has made tremendous progress, and the powerful natural language understanding and generation capabilities of these models have provided new ideas and possibilities for solving various complex software technology problems. In summary, the technical solution of this disclosure can leverage the powerful processing capabilities of machine learning models to generate simulated code for application programming interfaces, thereby improving the development and testing performance of applications.
[0034] Referring to Figure 2, which describes an overview of one implementation of this disclosure, Figure 2 shows a block diagram 200 for managing an application programming interface (API) according to some implementations of this disclosure. As shown in Figure 2, for an API (e.g., API 120) in application 110, description data 210 of that API can be obtained. Here, description data 210 can be defined in an Interface Description Language (IDL) and typically includes definitions of the API's interaction interfaces with the outside world (e.g., input and output interfaces) and the data structures involved, etc. Assuming that API 120 performs a user registration function, the data structures involved in description data 210 may include: field 220, identified as username and used to store the username; field 222, identified as password and used to store the password.
[0035] Furthermore, constraint data 230 can be obtained, which can represent constraints on the fields specified by description data 210, and the constraint data is represented in natural language. For example, for fields 220 and 222 in description data 210, the constraint data can specify: 1) the username must be between 6 and 20 characters long and cannot include special characters; 2) the password is a string type and at least 8 characters long, etc. Based on description data 210 and constraint data 230, machine learning models (e.g., model 240) can be used to determine mock code 250 for simulating the functionality of application programming interface 120. In a mock environment, mock code can be a concrete example of mock code. It should be understood that mock code 250 is code that can be correctly compiled and executed. Mock code 250 can be deployed in the application's execution environment to generate a mock interface for simulating the functionality of application programming interface 120.
[0036] Existing mock platforms or manual mock code writing methods cannot fully exploit the format and semantic constraints implicit in the interface field names themselves. For example, the content of the field "phoneNumber" should follow a specific telephone number format specification; the field "email" should follow a specific email address format specification, and so on. However, existing technical solutions struggle to automatically generate accurate mock data based on such semantic information. Unlike existing technical solutions, the proposed technical solution can accurately understand and utilize the semantic information of fields. Specifically, this disclosure can leverage machine learning models to enable the interface mocking process to deeply understand the semantics expressed by field names, thereby accurately generating mock content that conforms to the semantic requirements of the fields, thus reducing errors caused by insufficient understanding of the fields.
[0037] While existing mock platforms support generative mocking, writing generative mocks is complex, requiring developers to possess deep technical knowledge and extensive configuration experience, and the generated mock content often has poor readability. This presents developers with numerous difficulties when using, debugging, and maintaining mock interfaces. Unlike existing solutions, the proposed solution reduces the complexity of generative configuration and improves the readability of mock code. This disclosure simplifies the configuration process, reduces the complexity of generative configuration, and allows developers to more easily define mock rules. Simultaneously, it ensures that the generated mock content is highly readable, facilitating collaboration and communication among team members and improving the efficiency of the entire software development process.
[0038] This invention allows for the efficient integration of API definition languages (APIs) into the interface development process. In addition to the interface structure information defined by API IDLs, there are typically field relationship constraints described in natural language. Existing technical solutions struggle to effectively combine these natural language constraints with API IDL information, resulting in an inability to fully consider these constraints during mock interface generation, thus affecting the accuracy and completeness of the mock interfaces. Unlike existing technical solutions, the proposed solution integrates natural language constraints with API definitions. This disclosure efficiently integrates natural language-described constraints with API IDLs, allowing them to complement each other and providing a solid foundation for generating high-quality mock interfaces that meet various requirements. In this way, it ensures that mock interfaces accurately simulate the behavior of real interfaces under various complex business scenarios.
[0039] By utilizing some implementation methods disclosed herein, the powerful capabilities of the model can be leveraged to significantly improve the automation level of interface mocking and reduce manual intervention. Specifically, by analyzing API IDL and natural language constraints, high-quality, directly usable mock interface code can be automatically generated. This approach not only improves development efficiency but also reduces the error rate caused by human factors. Furthermore, it provides a more intelligent and convenient solution for interface testing and development in the software development process, accelerating the iteration of the entire software project.
[0040] Using some implementation methods disclosed herein, mock code can be automatically generated directly based on the description data of the application programming interface and constraints expressed in natural language. This approach reduces the manual workload in application development and testing, and improves development and testing efficiency.
[0041] Detailed process of interface management
[0042] Having described an overview of some implementations of this disclosure, further details regarding methods for managing application programming interfaces (APIs) will be described below. Figure 3 shows a block diagram 300 of the architecture of modules for managing APIs according to some implementations of this disclosure. According to some implementations of this disclosure, multiple modules can be used to manage APIs. Specifically, the multiple modules may include: a parsing module 310, a constraint processing module 320, a training module 330, a generation module 340, an execution module 350, and a verification module 360.
[0043] As shown in Figure 3, the parsing module 310 can receive API IDL and parse descriptive data about various aspects of the interface definition. The constraint processing module 320 can receive constraints expressed in natural language and determine the constraint data for each field defined in the application programming interface. Descriptive data and constraint data can be input to the generation module 340, which can call model 240 to generate mock code. Here, model 240 can be a machine learning model fully trained using training module 330. The execution module 350 can call the mock code to provide a mock interface. Furthermore, the verification module 360 can receive test requests and verify whether the mock interface functions correctly.
[0044] The following sections describe each module in more detail. According to some implementations of this disclosure, the parsing module 310 can obtain the description data of the application's application programming interface (API). Here, the description data can be represented using IDL. IDL is a standardized language for defining software component interfaces, widely used in distributed systems, cross-language service development, and other fields. It allows developers to define interfaces, data types, and methods in a programming language-independent manner, thereby achieving cross-platform and cross-language communication. IDL can support cross-language service definitions, define service interfaces and data structures, and support implementations in multiple programming languages. For example, dedicated tools can be used to generate code in different languages based on IDL files.
[0045] According to some implementations of this disclosure, the parsing module can parse information from API IDL. This module supports multiple IDL formats and parses various common API IDL formats, such as, but not limited to, Protobuf, Thrift, and OpenAPISpec. Different IDL formats can have dedicated syntax and structures for precisely defining API interface information. This disclosure provides a general workflow for parsing different IDL formats.
[0046] For example, for Protobuf format, various libraries in Python can be used to read the contents of the IDL file, and then parse the structural information such as interface endpoints, request messages, and response messages, as well as key elements such as the type and identifier of each field. In a simple example, the IDL can specify the name of the mock interface as "Register" and include two fields: "username" and "password," and so on. It should be understood that the content of the IDL is merely illustrative, and the content of the IDL can vary depending on the functionality of the API. For example, for an API that performs item search functionality, it may include "category" and "number" fields, and so on.
[0047] For Thrift format, the corresponding Thrift library can be used (different libraries are available for different programming languages). First, the IDL file is read and parsed to define services, methods, parameter types, structs, and other information. Thrift format defines data types in a struct-like format; the parsing process can identify these structures and their included fields, extracting important information such as the method name, parameter list, and return type corresponding to the service interface. For OpenAPI Spec, IDL is usually represented in JSON or YAML format. Relevant code libraries can be used to read the file content and parse out detailed information such as the API endpoint path, request method, request parameters, response status code, and data structure. After parsing, the obtained interface information can be passed to subsequent modules in its raw data structure form.
[0048] According to some implementations of this disclosure, a constraint processing module can be used to obtain constraint data, which represents constraints on fields specified by description data, and the constraint data is expressed in natural language. The constraint processing module can process constraints expressed in natural language. This module can receive constraints describing the relationships between fields as input by the developer, such as: "The username in the registration request must be between 6 and 20 characters long and cannot include special characters," "The password is a string and must be at least 8 characters long," and so on. For an API that performs an item query function, the constraint can be expressed as: "The category in the request parameter is a string, and the number must be greater than 0 and less than 10000," and so on. Using some implementations of this disclosure, the constraint processing module can directly and completely pass these constraints in natural language form to subsequent modules without requiring additional processing of the constraints within this module.
[0049] According to some implementations of this disclosure, a machine learning model can be used to generate mock code. Here, the machine learning model can be determined through the following steps: obtaining reference log data associated with a reference application programming interface (API), the reference log data including reference description data of the API and reference constraint data for reference fields specified in the reference description data; and updating the machine learning model using the reference log data and the reference code of the API. Using some implementations of this disclosure, historical knowledge in the log data can be fully utilized to train the machine learning model, enabling the machine learning model to accurately generate mock code.
[0050] Specifically, training module 330 can be used to train a machine learning model. This training module 330 can utilize API gateway logs to pre-train the machine learning model. For example, training samples can include log data collected by the API gateway of the relevant application. This log data can include API call information in a real-world environment, such as the endpoint of the request, parameters, timestamps, etc. It should be understood that preprocessing can be performed on the log data, such as removing invalid records, removing data that may involve data security risks, standardizing the data format, and extracting key information (such as the requested interface name, parameter values, and their corresponding response status codes), to form a structured format suitable for pre-training data. The training module can use the preprocessed training samples to update the machine learning model. By allowing the model to learn the data patterns of real API calls, it can better understand the actual usage of different interfaces, parameter distributions, and common response results.
[0051] It should be understood that the machine learning model here can be a machine learning model for performing a specific task. Alternatively and / or additionally, the machine learning model can be a language model for performing a general task. Different prompt words can be input into the language model so that the language model performs the corresponding task.
[0052] According to some implementations of this disclosure, in the process of determining mock code for simulating the functionality of an application programming interface (API) using a machine learning model, prompt words can be generated using descriptive data and constraint data. These prompt words can instruct the machine learning model to generate mock code. Responses from the machine learning model to the prompt words can be received as mock code. Specifically, the generation module 340 can invoke the machine learning model to determine the mock code for simulating the API functionality based on the descriptive data and constraint data. In this way, the powerful processing capabilities of the machine learning model can be utilized to automatically generate mock code.
[0053] According to some implementations of this disclosure, the generation module can interact with the machine learning model and generate code that can be correctly compiled and executed. Specifically, the generation module can combine the raw interface information received from the parsing module and the natural language constraints received from the constraint processing module, and can convert the combined comprehensive data structure (e.g., including API IDL information and natural language constraints) into a text format suitable for model input. For example, the prompt words shown in Table 1.
[0054] Table 1 Examples of prompt words
[0055] Furthermore, the generation module can interact with the model and send generation requests. These requests can specify the generation of interface mock code for a specific programming framework (such as Flask or Spring Boot) using a specific programming language (e.g., Python, Java) and input the aforementioned prompts into the model. The model can then generate the corresponding code based on the generation request and the prompts, while also considering API IDL information and natural language constraints. Since the model has been thoroughly trained, it can reference real API calls when generating mock code, making the generated code logically and in terms of results closer to real-world interface behavior. Specifically, the generated mock code can be invoked within the specified programming language environment and framework, thereby significantly reducing the enormous workload of manually generating mock code.
[0056] According to some implementations of this disclosure, the prompt words can further specify the programming language of the mock code, and the mock code is represented in a programming language. Although not shown in Table 1 above, the prompt words can further specify that the mock code is generated using programming languages such as Python or Java. Alternatively and / or additionally, the prompt words can further specify the programming framework that the mock code needs to follow. For example, the prompt words can further specify that the generated mock code follows programming frameworks such as Flask or Spring Boot. Using some implementations of this disclosure, it is possible to support the generation of mock code in a personalized manner, thereby supporting development and testing under different programming languages and programming frameworks.
[0057] According to some implementation methods of this disclosure, the mock code can be checked according to the syntax rules of the programming language. Specifically, the generation module 340 can also perform preliminary format checks and integrity verification on the generated mock code, and ensure that the basic structure of the mock code is complete and free of obvious syntax errors. For example, it can check whether the brackets in the mock code are matched, whether the keywords are used correctly, whether the functions are used correctly, and whether the route definitions are accurate, etc.
[0058] Based on some implementation methods of this disclosure, for the prompt words shown in Table 1 above, illustrative code as shown in Table 2 below can be generated. It should be understood that Table 2 shows the core information that needs to be included in the mock code in pseudocode form. In different programming language environments, the mock code can have different statement formats.
[0059] Table 2 Illustrative Codes
[0060] In Table 2, code snippet 1 represents the user registration function "Mock_register()", code snippet 2 represents the process of obtaining the username and password, code snippet 3 represents the process of verifying the username, code snippet 4 represents the process of verifying the password, and code snippet 5 represents the process of simulating the generation of response data such as the username. Based on some implementation methods of this disclosure, the generated Mock code can be edited and / or adjusted to make the code functionality better match the expected goals.
[0061] According to some implementations of this disclosure, mock code can be deployed in the application's execution environment to generate mock interfaces that simulate the application's application programming interface functionality. Specifically, the execution module can call the mock code and can run in various environments.
[0062] According to some implementations of this disclosure, the execution environment can be a gateway environment. During the process of generating a mock interface for the functionality of an application programming interface (API) simulating an application, mock code can be deployed at a location specified by the gateway of the API. A path for accessing the deployed mock code can be set to generate the mock interface for the functionality of the API simulating an application. In this way, calling the mock code in the gateway environment can be supported.
[0063] See Figure 4 for further details, which illustrates a block diagram 400 of deploying mock code in a gateway environment according to some implementations of this disclosure. As shown in Figure 4, mock code 250 can be deployed in gateway environment 410. For example, a code script (e.g., Python) can be hosted at the API gateway. Assuming the API gateway supports a Python plugin, the mock code for the generated interface can run in the API gateway environment. The API gateway can be responsible for receiving requests and providing responses to those requests; for example, a Python plugin can be invoked to generate and return the response content.
[0064] Routing rules can be configured in the API gateway using configuration file 420 (e.g., in JSON or YAML format), which associates interface endpoints (e.g., / register) retrieved from the API IDL with corresponding Python script functions. For example, the association can be set in the API gateway's configuration file. The illustrative code shown in Table 2 above can be associated using the method shown in Table 3 below. It should be understood that Table 3 illustrates the core information for performing the association operation in pseudocode form; different formats of association code may exist in different programming language environments. As shown in Table 3, the keyword "routes" can represent a path, the keyword "uri" can represent the interface endpoint as " / register", the keyword "python_script" can represent the file storing the code script as Mock_register.py, and the keyword "function_name" can represent the function name as Mock_register, and so on.
[0065] Table 3 Related Codes
[0066] Regarding deployment and execution, the code script can be deployed to the script storage location specified by the API gateway. When a request arrives at the corresponding endpoint of the API gateway, the API gateway can load the corresponding code script, call the configured function, and pass the request data to that function for processing. Inside the function, based on the previously defined logic, it can verify whether the request conforms to natural language constraints (such as username length, password format, etc.), and then generate the corresponding response data and return it to the API gateway. The API gateway can then return the response data to the client.
[0067] According to some implementations of this disclosure, the execution environment can be a web integration environment. During the process of generating a mock interface for the application programming interface (API) of a simulated application, the mock code can be compiled into a web integration module; and the web integration module can be deployed in the web integration environment to generate the mock interface for the API of the simulated application. In this way, calling the mock code within the web integration environment can be supported.
[0068] See Figure 5 for further details, which illustrates a block diagram 500 of deploying mock code in a web integration environment according to some implementations of this disclosure. As shown in Figure 5, the mock code 250 can be compiled into the format of a web integration module 520, and the web integration module can be deployed in a web integration environment 510.
[0069] At this point, execution module 350 can support Web Interface Integration (WASM) logic. WASM is a binary instruction format that runs in browsers and other environments. The generated interface mock code can be compiled into a WASM module. For example, various tools can be used to compile Python-Flask code (assuming it has been appropriately modified to be compileable) into WASM format. During compilation, the input / output interfaces and internal execution logic of the WASM module can be configured based on the interface information and natural language constraints parsed from the API IDL. For example, for the / register interface, the WASM module can be configured to receive a username and password, verify that the username and password meet the constraints, and then generate the corresponding username and message as output.
[0070] The compiled WASM module can be deployed to environments that support WASM execution, such as certain specialized edge computing devices and web servers. When a request arrives at the corresponding interface endpoint, the WASM module can be loaded and executed in the execution environment. It processes the request according to its internal logic, verifies whether the request is processed according to natural language constraints (such as username length and password format), and returns the corresponding response data.
[0071] According to some implementations of this disclosure, the execution environment can be a container environment. In the process of generating a mock interface for the functionality of simulating an application's application programming interface (API), the dependencies of the mock code can be loaded into a container within the container environment; the mock code can be deployed to the container; and a service can be created to call the mock code in the container to generate the mock interface for the functionality of simulating an application's API. In this way, calling mock code in a container environment can be supported.
[0072] See Figure 6 for further details, which illustrates a block diagram 600 of deploying mock code in a container environment according to some implementations of this disclosure. As shown in Figure 6, execution module 350 can be implemented in container environment 610. Specifically, mock code can be automatically deployed to a Function as a Service (FaaS) container (e.g., container 620). The mock code for the generated interface can be executed in container environment 610.
[0073] According to some implementations of this disclosure, container images can be created, which can include dependencies required to run mock code, such as programming language runtime environments (e.g., Python interpreters), related libraries, etc. For the example above, the base image can be specified in the container's configuration file, necessary libraries can be installed (e.g., based on actual IDL parsing and code requirements), and the mock code can be copied into the container. The container image can be deployed to a cluster to provide FaaS services (e.g., service 540). Resources can be created to manage container replicas, enabling the mock service to be accessible within the cluster. The service type can be modified to expose the service outside the cluster. When a request arrives at the corresponding API endpoint (e.g., / register), the cluster can route the request to the running container instance. The container instance executes the mock code, verifies that the request conforms to natural language constraints (e.g., username length, password format, etc.), and returns the corresponding response data.
[0074] According to some implementations of this disclosure, machine learning models can be used to generate test samples for testing mock code. Test samples can be provided to the mock interface for testing the mock code. Using some implementations of this disclosure, the correctness of the generated mock code can be further verified, and potential errors in the mock code can be adjusted. The above process can be performed using a verification module 360.
[0075] According to some implementations of this disclosure, the verification module 360 can test request sending. Specifically, automated testing tools can be used to send various test requests to the Mock interface. These test requests can include normal requests that conform to the interface definition and constraints, as well as abnormal requests that violate the constraints. For example, for the user registration interface, normal requests including a valid username and password can be sent, as well as abnormal requests such as usernames that are too short or contain special characters, etc.
[0076] Furthermore, the verification module 360 can verify the response. Specifically, the verification module 360 can verify whether the response of the mock interface meets expectations. In other words, the verification module can check whether the response status code is correct, whether the response data structure is consistent with the API IDL definition, and whether it meets natural language constraints. For example, if the registration interface returns an error status code and the corresponding error message "username length or format does not meet requirements" when the username does not meet the requirements, the verification module can check whether the actual response meets this requirement, and so on.
[0077] According to some implementations of this disclosure, during the testing of mock code, test samples can be processed using a mock interface to generate test results. In response to determining that the test results match the predicted test results corresponding to the test samples, a message indicating successful testing can be provided. Using some implementations of this disclosure, the execution results of the mock code can be presented visually, thereby verifying whether the mock code is accurate and can be correctly compiled and executed.
[0078] Specifically, the verification module 360 can generate feedback information based on the verification results. If the Mock interface responds correctly, it records successful test cases and related information; if the response is incorrect, it records detailed error types, error locations (such as line numbers), and the difference between expected and actual results. This feedback information will be used for subsequent optimization and debugging, thereby continuously improving the quality and accuracy of the Mock interface. Test reports can be generated, for example, displaying test results in tabular form, as shown in Table 4 below.
[0079] Table 4 Test Results
[0080] Within the context of this disclosure, a complete workflow for managing application programming interfaces (APIs) is provided. This workflow includes: API IDL parsing, natural language constraint processing, model interaction and code generation, automated execution of managed code, and verification and feedback. This workflow can be executed by multiple modules, which can operate collaboratively. A method is provided for pre-training models using existing API gateway logs from the developer's relevant applications, including data collection, preprocessing, and setting appropriate parameters during pre-training. This pre-training method improves model generation capabilities and generates mock code that approximates real values. Furthermore, an interaction mechanism with different IDL formats and execution environments is provided: specific mechanisms and configuration methods for parsing and processing various API IDL formats and interacting with different execution environments (such as API gateways, WASM environments, container environments, etc.) to achieve automated execution of mock code.
[0081] Within the context of this disclosure, code generation logic based on natural language constraints is provided: natural language constraints are integrated into the mock code generation process of the model interface, ensuring that the generated code accurately follows the specific logic and implementation of these constraints, including the model's understanding and conversion of natural language constraints and their application in code generation. Test requests can be sent, verification responses can be generated, and feedback information can be produced, thereby guaranteeing the quality and accuracy of the mock interface. Furthermore, a mechanism for subsequent optimization and debugging can be utilized using the feedback information.
[0082] Based on some implementation methods disclosed herein, by utilizing the collaborative work of the various modules described above, it is possible to automatically generate mock code from interfaces based on various forms of API IDL. This approach improves the efficiency, accuracy, and intelligence of interface mocking, providing strong support for interface testing and development during the software development process.
[0083] Based on some implementation methods of this disclosure, multi-format API IDL parsing and processing can be supported. Specifically, the technical solution of this disclosure can parse various common API IDL formats, extract key information such as interface endpoints, request messages, and response messages, and organize them into a unified structured data model for use by subsequent modules. In this way, compatible processing of different IDL formats can be achieved, providing basic data support for automatic interface mocking.
[0084] According to some implementations of this disclosure, natural language constraint processing can be supported. Field constraints described in natural language by developers are received and directly passed to the model. The model, trained on a large number of samples (including pre-training using internal API gateway logs), integrates these constraints with parsed API IDL information, converting the natural language constraints into prompts that can be used to generate code, enabling the generated mock code to meet specific business logic requirements.
[0085] Based on some implementation methods disclosed herein, model-driven code generation can be supported. Leveraging the powerful natural language processing and code generation capabilities of the model, and based on integrated API IDL information and natural language constraints, mock code for interfaces in specific programming languages and frameworks can be generated. Furthermore, by pre-training the model to make the generated results closer to the real values, the efficiency and accuracy of mock code generation can be improved.
[0086] Based on some implementation methods disclosed herein, automated execution via a managed runtime can be supported. Specifically, multiple execution methods can be provided, including execution of Python scripts hosted via an API gateway (adapting to the API gateway environment and configuring routing rules), execution of WASM logic (compiling and configuring the WASM module), and automated deployment of FaaS services. In this way, the generated mock code can be executed in different runtime environments without complex integration operations.
[0087] According to some implementation methods of this disclosure, a verification and feedback mechanism can be supported. By sending various test requests (including normal and abnormal requests) to the automatically executed Mock interface, the system verifies whether its response meets expectations (including status codes, data structures, and natural language constraints, etc.), and generates feedback information based on the verification results for subsequent optimization and debugging, ensuring the quality and accuracy of the Mock interface.
[0088] By utilizing some implementation methods disclosed herein, superior technical effects can be achieved compared to existing technical solutions. The proposed technical solution can improve the efficiency of generating mock code. Specifically, by parsing and uniformly processing various common API IDL formats, interface definition information can be quickly obtained. This provides an accurate foundation for subsequent mock code generation, reduces the tedious process of manually handling different formats, and accelerates the overall process of interface mocking. Leveraging the model's powerful natural language processing and code generation capabilities, mock code for the desired programming language and framework can be directly generated based on the integrated API IDL information and natural language constraints. This eliminates the need for developers to manually write large amounts of code, significantly improving code generation speed and thus enhancing the efficiency of interface mocking.
[0089] Based on some implementation methods disclosed herein, the accuracy of mock code can be improved. By leveraging models trained on a large number of samples (including pre-training using logs from the company's internal API gateway), the models gain a deeper understanding of actual API usage and parameter distribution, resulting in mock code that more closely resembles real-world interface behavior in both logic and outcome. This improves the matching degree between mock code and real interfaces, enhancing accuracy. Furthermore, by effectively incorporating field constraints described in natural language during mock code generation, the generated code strictly adheres to these constraints for request validation and response generation, further guaranteeing the accuracy of the mock code at the business logic level.
[0090] By utilizing some implementation methods disclosed herein, the intelligence level of the model can be improved. For example, semantic extraction, data structure organization, and conversion of natural language constraints into a format suitable for code generation can be automatically performed on the parsed API IDL information, reducing manual intervention and demonstrating a high degree of intelligence. By automatically adapting and deploying to different managed runtime environments, the automatic execution of mock code is achieved without requiring complex integration operations by developers, demonstrating the intelligence of the entire system in runtime processing.
[0091] By utilizing some implementation methods of this disclosure, diverse execution environments can be provided, covering various approaches such as API gateway-hosted Python script execution, WASM execution logic, and automatic deployment to FaaS services. This allows this disclosure to adapt to different application scenarios and technical architectures, providing developers with greater flexibility in choosing the execution environment.
[0092] By utilizing some implementation methods disclosed herein, the quality of mock interfaces can be effectively guaranteed. Specifically, the automatically executed mock interfaces are comprehensively verified by sending various test requests (including normal and abnormal requests). This allows for checking response status codes, data structures, and compliance with natural language constraints, and timely identification and recording of potential problems with the mock interfaces. Furthermore, the feedback information generated based on the verification results can be used for subsequent optimization and debugging. Through continuous adjustment and improvement, the quality of the mock interfaces is continuously enhanced, ensuring that they accurately simulate the behavior of real interfaces and meet the interface testing and development needs in the software development process.
[0093] Example process
[0094] Figure 7 illustrates a flowchart of a method 700 for managing an application programming interface (API) according to some implementations of this disclosure. At block 710, description data of the application's API is obtained. At block 720, constraint data is obtained, representing constraints on fields specified by the description data, and the constraint data is represented in natural language. At block 730, based on the description data and the constraint data, simulation code for simulating the functionality of the API is determined using a machine learning model. At block 740, the simulation code is deployed in the application's execution environment to generate a simulation interface for simulating the functionality of the application's API.
[0095] According to some implementations of this disclosure, determining the simulation code for simulating the function of the application programming interface using a machine learning model includes: generating a prompt word using the description data and the constraint data, the prompt word instructing the machine learning model to generate the simulation code; and receiving a response from the machine learning model to the prompt word as the simulation code.
[0096] According to some implementations of this disclosure, the prompt word further specifies the programming language of the simulation code, and the simulation code is represented in the programming language.
[0097] According to some implementations of this disclosure, the method 700 further includes: checking the simulated code according to the syntax rules of the programming language.
[0098] According to some implementations of this disclosure, the machine learning model is determined by the following steps: obtaining reference log data associated with a reference application programming interface (API), the reference log data including reference description data of the API and reference constraint data for reference fields specified in the reference description data; and updating the machine learning model using the reference log data and the reference code of the API.
[0099] According to some implementations of this disclosure, the execution environment is a gateway environment, and generating the simulation interface for simulating the functionality of the application programming interface of the application includes: deploying the simulation code at a location specified by the gateway of the application programming interface; and setting a path for accessing the deployed simulation code to generate the simulation interface for simulating the functionality of the application programming interface of the application.
[0100] According to some implementations of this disclosure, the execution environment is a web integration environment, and generating the simulation interface for simulating the function of the application programming interface of the application includes: compiling the simulation code into a web integration module; and deploying the web integration module in the web integration environment to generate the simulation interface for simulating the function of the application programming interface of the application.
[0101] According to some implementations of this disclosure, the execution environment is a container environment, and the simulation interface for generating the function of the application programming interface for simulating the application includes: loading the dependencies of the simulation code in a container in the container environment; deploying the simulation code to the container; and creating a service for calling the simulation code in the container to generate the simulation interface for simulating the function of the application programming interface for simulating the application.
[0102] According to some implementations of this disclosure, the method 700 further includes: generating test samples for testing the mock code using a machine learning model; and providing the test samples to the mock interface for testing the mock code.
[0103] According to some implementations of this disclosure, testing the simulation code includes: processing the test sample using the simulation interface to generate test results; and providing a prompt message indicating that the test was successful in response to determining that the test results are consistent with the predicted test results corresponding to the test sample.
[0104] Example devices and equipment
[0105] Figure 8 shows a block diagram of an apparatus 800 for managing application programming interfaces (APIs) according to some implementations of the present disclosure. The apparatus includes: a description data acquisition module 810 configured to acquire description data of an application's API; a constraint data acquisition module 820 configured to acquire constraint data, the constraint data representing constraints on fields specified by the description data, and the constraint data being represented in natural language; a determination module 830 configured to determine, based on the description data and the constraint data, simulation code for simulating the functionality of the API using a machine learning model; and a generation module 840 configured to deploy the simulation code in the execution environment of the application to generate a simulation interface for simulating the functionality of the application's API.
[0106] According to some implementations of this disclosure, the determining module 830 is further configured to: generate a prompt word using the description data and the constraint data, the prompt word instructing the machine learning model to generate the simulation code; and receive a response from the machine learning model to the prompt word as the simulation code.
[0107] According to some implementations of this disclosure, the prompt word further specifies the programming language of the simulation code, and the simulation code is represented in the programming language.
[0108] According to some implementations of this disclosure, the device 800 further includes a processing module configured to: examine the simulated code according to the syntax rules of the programming language.
[0109] According to some implementations of this disclosure, the machine learning model is determined by the following steps: obtaining reference log data associated with a reference application programming interface (API), the reference log data including reference description data of the API and reference constraint data for reference fields specified in the reference description data; and updating the machine learning model using the reference log data and the reference code of the API.
[0110] According to some implementations of this disclosure, the execution environment is a gateway environment, and the generation module 840 is further configured to: deploy the mock code at a location specified by the gateway of the application programming interface; and set a path for accessing the deployed mock code to generate the mock interface for simulating the functionality of the application programming interface of the application.
[0111] According to some implementations of this disclosure, the execution environment is a web page integration environment, and the generation module 840 is further configured to: compile the simulation code into a web page integration module; and deploy the web page integration module in the web page integration environment to generate the simulation interface for simulating the function of the application programming interface of the application.
[0112] According to some implementations of this disclosure, the execution environment is a container environment, and the generation module 840 is further configured to: load the dependencies of the mock code in a container in the container environment; deploy the mock code to the container; and create a service for calling the mock code in the container to generate the mock interface for simulating the function of the application programming interface of the application.
[0113] According to some implementations of this disclosure, the processing module is further configured to: generate test samples for testing the mock code using a machine learning model; and provide the test samples to the mock interface for testing the mock code.
[0114] According to some implementations of this disclosure, the processing module is further configured to: process the test sample using the simulation interface to generate test results; and, in response to determining that the test results are consistent with the predicted test results corresponding to the test sample, provide a prompt message indicating that the test was successful.
[0115] Figure 9 shows a block diagram of a device 900 that can implement various implementations of the present disclosure. It should be understood that the computing device 900 shown in Figure 9 is merely exemplary and should not constitute any limitation on the functionality and scope of the implementations described herein. The computing device 900 shown in Figure 9 can be used to implement the methods described above.
[0116] As shown in Figure 9, the computing device 900 is in the form of a general-purpose computing device. Components of the computing device 900 may include, but are not limited to, one or more processors 910, memory 920, storage devices 930, one or more communication units 940, one or more input devices 950, and one or more output devices 960. The processor 910 may be a physical or virtual processor and can perform various processes according to the programs stored in the memory 920. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of the computing device 900.
[0117] Computing device 900 typically includes multiple computer storage media. Such media can be any available media accessible to computing device 900, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 920 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 930 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data (e.g., training data for training) and can be accessed within computing device 900.
[0118] The computing device 900 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 9, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks may be provided. In these cases, each drive may be connected to a bus (not shown) via one or more data media interfaces. The memory 920 may include a computer program product 925 having one or more program modules configured to perform various methods or actions of various implementations of the present disclosure.
[0119] The communication unit 940 enables communication with other computing devices via a communication medium. Additionally, the functionality of the components of the computing device 900 can be implemented as a single computing cluster or multiple computing machines that can communicate via communication connections. Therefore, the computing device 900 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.
[0120] Input device 950 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 960 can be one or more output devices, such as a monitor, speaker, printer, etc. Computing device 900 can also communicate as needed with one or more external devices (not shown) via communication unit 940. These external devices, such as storage devices, display devices, etc., can communicate with one or more devices that enable user interaction with computing device 900, or with any device (e.g., network card, modem, etc.) that enables computing device 900 to communicate with one or more other computing devices. Such communication can be performed via input / output (I / O) interfaces (not shown).
[0121] According to an implementation of this disclosure, a computer-readable storage medium is provided, on which computer-executable instructions are stored, wherein the computer-executable instructions are executed by a processor to implement the method described above. According to an implementation of this disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the method described above. According to an implementation of this disclosure, a computer program product is provided, on which a computer program is stored, which, when executed by a processor, implements the method described above.
[0122] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0123] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.
[0124] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.
[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0126] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various implementations disclosed herein.
Claims
1. A method for managing application programming interfaces, comprising: Obtain the description data of the application's application programming interface; Obtain constraint data, which represents constraints on fields specified by the description data, and the constraint data is represented in natural language; Based on the description data and the constraint data, a machine learning model is used to determine the simulation code used to simulate the functionality of the application programming interface; as well as The emulation code is deployed in the execution environment of the application to generate a emulation interface for emulating the functionality of the application programming interface of the application.
2. The method of claim 1, wherein determining the simulation code for simulating the functionality of the application programming interface using a machine learning model comprises: Using the description data and the constraint data, prompt words are generated, which instruct the machine learning model to generate the simulation code; as well as The machine learning model receives a response to the prompt word as the simulated code.
3. The method of claim 1, wherein the prompt word further specifies the programming language of the simulation code, and the simulation code is represented in the programming language.
4. The method of claim 3, further comprising: The simulated code is examined according to the syntax rules of the programming language.
5. The method of claim 1, wherein the machine learning model is determined by the following steps: Obtain reference log data associated with the reference application programming interface (API), the reference log data including reference description data of the reference API and reference constraint data for reference fields specified in the reference description data; and The machine learning model is updated using the reference log data and the reference code of the reference application programming interface.
6. The method of claim 1, wherein the execution environment is a gateway environment, and the simulation interface for generating the functionality of the application programming interface for simulating the application comprises: The mock code is deployed at the location specified by the gateway of the application programming interface; as well as Set a path for accessing the deployed mock code to generate the mock interface for simulating the functionality of the application programming interface of the application.
7. The method of claim 1, wherein the execution environment is a web page integration environment, and the simulation interface for generating the functionality of the application programming interface for simulating the application comprises: The simulated code is compiled into a web page integration module; as well as The web integration module is deployed in the web integration environment to generate the simulated interface for simulating the functions of the application programming interface of the application.
8. The method of claim 1, wherein the execution environment is a container environment, and the simulation interface for generating the functionality of the application programming interface for simulating the application comprises: Load the dependencies of the mock code into a container within the container environment; Deploy the simulation code to the container; as well as A service is created for invoking the simulated code in the container to generate the simulated interface for simulating the functionality of the application programming interface of the application.
9. The method of claim 1, further comprising: Test samples for testing the simulated code are generated using a machine learning model; as well as The test sample is provided to the simulation interface to test the simulation code.
10. The method of claim 9, wherein testing the simulation code comprises: The test samples are processed using the simulation interface to generate test results; as well as In response to determining that the test result is consistent with the predicted test result corresponding to the test sample, a prompt message indicating that the test was successful is provided.
11. An apparatus for managing an application programming interface, comprising: The description data acquisition module is configured to acquire description data of the application's application programming interface. A constraint data acquisition module is configured to acquire constraint data, which represents constraints on fields specified by the description data, and the constraint data is represented in natural language. The determination module is configured to determine, based on the description data and the constraint data, simulation code for simulating the functionality of the application programming interface using a machine learning model; as well as A generation module is configured to deploy the mock code in the execution environment of the application to generate a mock interface for simulating the functionality of the application programming interface of the application.
12. An electronic device, comprising: At least one processor; as well as At least one memory, coupled to the at least one processor and storing instructions for execution by the at least one processor, which, when executed by the at least one processor, cause the electronic device to perform the method according to any one of claims 1 to 10.
13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 10.
14. A computer instruction product comprising computer instructions, wherein the computer instructions, when executed by a processor, implement the method according to any one of claims 1 to 10.