Application programming interface arrangement method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to an application programming interface arrangement method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the steps of generating an execution task queue of target application programming interfaces (API) based on pre-stored target metadata of the APIs needing to be arranged; according to the execution task queue, calling the target APIs in sequence; if the target API fails to call and a preset rollback condition is met, constructing a rollback task queue of the target API in an inverted sequence based on pre-stored rollback metadata of rollback APIs corresponding to the target APIs; and according to the rollback task queue, calling the rollback APIs in sequence until all the rollback APIs are called completely. By adopting the method, the atomicity and the consistency of the whole process can be ensured.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a method, apparatus, computer device, computer-readable storage medium, and computer program product for arranging an application programming interface. Background Art

[0002] As digital transformation deepens, enterprises and service providers increasingly rely on microservice architecture and application programming interfaces (APIs) to build and deliver complex functions. APIs not only serve as a communication bridge for internal services, but also an important interface for providing services to the outside world. However, as the number and complexity of APIs increase, calling a single API can no longer meet business needs. API orchestration systems have emerged to integrate multiple APIs to form a coherent and efficient business process.

[0003] Although the API orchestration system has brought many conveniences, it still faces some challenges in practical applications. In complex processes involving multiple APIs, the relevant API orchestration methods are prone to some API call failures, which may lead to inconsistent states of the entire process. Therefore, the relevant API orchestration methods cannot ensure the atomicity and consistency of the entire process. Summary of the invention

[0004] Based on this, it is necessary to provide an application programming interface orchestration method, apparatus, computer device, computer-readable storage medium and computer program product that can ensure the atomicity and consistency of the entire process in response to the above technical problems.

[0005] In a first aspect, the present application provides a method for arranging an application programming interface, comprising:

[0006] Based on pre-stored target metadata of each target application programming interface API that needs to be arranged, generating an execution task queue of the target API;

[0007] According to the execution task queue, calling each of the target APIs in sequence;

[0008] If there is a target API call failure and the preset rollback condition is met, then the rollback task queue of the target API is constructed in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each target API;

[0009] According to the rollback task queue, the rollback APIs are called in sequence until each rollback API call is completed.

[0010] In one embodiment, the step of generating an execution task queue of each target application programming interface API based on pre-stored target metadata of each target application programming interface API to be arranged includes:

[0011] Determine the API call sequence based on pre-stored target metadata of each target application programming interface API that needs to be arranged;

[0012] The API call sequence is organized into a first-in-first-out queue to obtain an execution task queue of the target API.

[0013] In one of the embodiments, in the event of a target API call failure, the method further includes:

[0014] If the number of retries of the target API is less than a preset retry threshold and does not meet the preset rollback rule, then re-call the target API;

[0015] If the number of retries of the target API reaches a preset retry threshold, or satisfies the rollback rule, it is determined that the preset rollback condition is met.

[0016] In one embodiment, the method further comprises:

[0017] If there is a rollback API call failure, the rollback API is called again according to the preset rollback retry conditions until the rollback API call is completed.

[0018] In one embodiment, the method further comprises:

[0019] When calling an API, writing the first resource ID of the generated resource or the second resource ID of the destroyed resource into context information; the API includes the target API and the calling API;

[0020] When each of the target API calls is completed or each of the rollback API calls is completed, the process integrity information and data consistency information of this call are determined according to the final state of this call and the context information; the final state includes the creation information or destruction information corresponding to each resource.

[0021] In one embodiment, the method further comprises:

[0022] When calling an API, recording the calling operation information of the API; the API includes the target API and the calling API; the calling operation information includes request parameters, response results, retry records and rollback operations;

[0023] Audit information and / or troubleshooting information is determined based on the call operation information.

[0024] In a second aspect, the present application also provides an application programming interface arrangement device, including:

[0025] A generation module, used for generating an execution task queue of each target application programming interface API that needs to be arranged based on pre-stored target metadata of the target API;

[0026] A first calling module, used for calling each of the target APIs in sequence according to the execution task queue;

[0027] A construction module, configured to construct a rollback task queue of the target API in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each of the target APIs if a target API call fails and the preset rollback condition is met;

[0028] The second calling module is used to call the rollback API in sequence according to the rollback task queue until each rollback API call is completed.

[0029] In one embodiment, the generating module is specifically used for:

[0030] Determine the API call sequence based on pre-stored target metadata of each target application programming interface API that needs to be arranged;

[0031] The API call sequence is organized into a first-in-first-out queue to obtain an execution task queue of the target API.

[0032] In one of the embodiments, in the event of a target API call failure, the apparatus further comprises:

[0033] A first recall module, configured to recall the target API if the number of retries of the target API is less than a preset retry threshold and does not satisfy a preset rollback rule;

[0034] The first determination module is used to determine whether a preset rollback condition is met if the number of retries of the target API reaches a preset retry threshold or satisfies the rollback rule.

[0035] In one embodiment, the device further comprises:

[0036] The second re-calling module is used to re-call the rollback API according to a preset rollback retry condition if there is a rollback API call failure until the rollback API call is completed.

[0037] In one embodiment, the device further comprises:

[0038] A writing module, used for writing the first resource ID of the generated resource or the second resource ID of the destroyed resource into the context information when calling an API; the API includes the target API and the calling API;

[0039] The second determination module is used to determine the process integrity information and data consistency information of this call according to the final state of this call and the context information when each target API call is completed or each rollback API call is completed; the final state includes the creation information or destruction information corresponding to each resource.

[0040] In one embodiment, the device further comprises:

[0041] A recording module, used to record the calling operation information of the API when calling the API; the API includes the target API and the calling API; the calling operation information includes request parameters, response results, retry records and rollback operations;

[0042] The third determination module is used to determine audit information and / or troubleshooting information according to the calling operation information.

[0043] In a third aspect, the present application further provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the steps described in the first aspect when executing the computer program.

[0044] In a fourth aspect, the present application further provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps described in the first aspect above.

[0045] In a fifth aspect, the present application further provides a computer program product, comprising a computer program, which implements the steps described in the first aspect when executed by a processor.

[0046] The above-mentioned method, apparatus, computer device, computer-readable storage medium and computer program product for arranging application programming interfaces generate an execution task queue of the target API based on the pre-stored target metadata of each target application programming interface API that needs to be arranged; call each target API in sequence according to the execution task queue; if there is a target API call failure and the preset rollback condition is met, then build a rollback task queue of the target API in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each target API; call the rollback API in sequence according to the rollback task queue until each rollback API call is completed. In this way, an execution task queue is generated according to the metadata of the target API, and the target API is called in sequence. When the target API call fails and the rollback condition is met, the rollback task queue is built in reverse order according to the metadata of the rollback API corresponding to the target API, and the rollback API is called in the opposite order of calling the target API to complete the rollback of the entire process. The multi-level compensation based on API orchestration is performed through the rollback interface corresponding to the registration interface. It is ensured that in a complex process involving multiple APIs, even if some API calls fail, they can be restored to a consistent state of the transaction through the rollback mechanism. The atomicity of the entire orchestration process can be achieved in any case, that is, either all succeed or all roll back, thereby ensuring the integrity of the business process and the consistency of the data. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the drawings required for use in the embodiments of the present application or related technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0048] FIG1 is a schematic diagram of a flow chart of a method for arranging an application programming interface in one embodiment;

[0049] FIG. 2 is a flowchart of steps for generating an execution task queue of a target API based on pre-stored target metadata of each target application programming interface API that needs to be arranged in one embodiment;

[0050] FIG3 is a flowchart of steps further included in the method in the case where a target API call fails in one embodiment;

[0051] FIG4 is a flow chart of steps further included in the method in one embodiment;

[0052] FIG5 is a flow chart of steps further included in the method in another embodiment;

[0053] FIG6 is a structural block diagram of an arrangement device for an application programming interface in one embodiment;

[0054] FIG. 7 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0055] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0056] In one embodiment, as shown in FIG1 , a method for arranging an application programming interface is provided. This embodiment uses the method applied to a terminal as an example for illustration. It is understandable that the method can also be applied to a server, and can also be applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. Among them, the terminal can be, but is not limited to, various personal computers, laptops, smart phones, tablet computers, Internet of Things devices and portable wearable devices. The Internet of Things devices can be smart speakers, smart TVs, smart air conditioners, smart car-mounted devices, projection devices, etc. Portable wearable devices can be smart watches, smart bracelets, head-mounted devices, etc. The head-mounted device can be a virtual reality (VR) device, an augmented reality (AR) device, smart glasses, etc. The server can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides cloud computing services. In this embodiment, the method includes the following steps:

[0057] Step 101 : generating an execution task queue of a target API based on pre-stored target metadata of each target application programming interface API that needs to be arranged.

[0058] In the embodiment of the present application, an application programming interface (API) is a set of predefined functions or procedures for building software applications. The API specifies how software components interact with each other, including communication rules between different software modules, operating systems, or remote services. The API allows developers to use the functions of a system or library without having to deeply understand the inner workings of it, thereby simplifying the software development process and improving efficiency. Orchestration: In the IT industry, especially in the fields of cloud computing, automation, and system integration, orchestration refers to the automatic coordination and management of processes of multiple complex systems to ensure that they run correctly in a predetermined order and conditions. In business process automation, orchestration tools help design and execute complex workflows across systems, ensuring that each step is executed in a logical order, improving business efficiency and responsiveness. Atomicity: In computer science and database theory, atomicity refers to the indivisibility of operations. An operation is called atomic, which means that it is either executed completely or not executed at all. Atomicity is a key attribute in transaction processing and is one of the ACID (atomicity, consistency, isolation, and persistence) attributes. In transaction processing, atomicity ensures that even in the event of a system crash or power failure, all operations in a transaction are either completed or not executed at all, thus maintaining data consistency.

[0059] The target API is the API that needs to be orchestrated. A business process can include at least one target API. The orchestration method of the application programming interface is used to integrate multiple target APIs to form a coherent business process. The target metadata may include request parameters and response parameters, and may also include one or more of context information, Uniform Resource Locator (URL) and calling methods. The response parameters may include an identity document (ID). Context information, also known as upper and lower parameters and context fields, referred to as context, is a context field that needs to be persisted in the orchestration process and is used for process status tracking to ensure the continuity of the process status. The calling method is the calling method of the API. The execution task queue is used to indicate the execution order of the target API and can be in the form of a first-in-first-out (FIFO) queue.

[0060] Step 102, calling each target API in sequence according to the execution task queue.

[0061] In the embodiment of the present application, the terminal calls each target API in turn according to the execution order of each target API in the execution task queue. After the previous target API is called, the next target API is called.

[0062] Step 103: If there is a target API call failure and the preset rollback condition is met, a rollback task queue of the target API is constructed in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each target API.

[0063] In an embodiment of the present application, if there is a target API call failure and the preset rollback condition is met, the terminal builds a rollback task queue of the target API based on the rollback metadata of the rollback API corresponding to each target API stored in advance, in the opposite order of the execution task queue of the target API. Specifically, the terminal determines the rollback call order of the rollback API corresponding to each target API based on the rollback metadata of the rollback API corresponding to each target API stored in advance and the order opposite to the execution order of each target API in the execution task queue. Then, the terminal organizes the rollback call order into a first-in-first-out queue to obtain the rollback task queue of the target API. Among them, the rollback condition is used to measure whether to trigger the rollback operation. The rollback API corresponds to the target API and the operation is opposite. For example, the target API is a cloud host activation API, and its corresponding rollback API is a cloud host destruction API. The rollback metadata can be similar to the target metadata, or it can only include response parameters. The order of the target APIs corresponding to the rollback API in the rollback task queue is opposite to the order of the target APIs in the execution task queue.

[0064] Step 104, calling the rollback APIs in sequence according to the rollback task queue until all rollback API calls are completed.

[0065] In the embodiment of the present application, the terminal calls each rollback API in turn according to the rollback order of each rollback API in the rollback task queue until each rollback API call is completed. After the previous rollback API call is completed, the next rollback API is called.

[0066] In the above-mentioned method for arranging the application programming interface, an execution task queue is generated according to the metadata of the target API, and the target API is called in sequence. When the target API call fails and the rollback condition is met, the rollback task queue is constructed in reverse order according to the metadata of the rollback API corresponding to the target API, and the rollback API is called in the opposite order of calling the target API to complete the rollback of the entire process. The rollback interface corresponding to the registration interface is used for multi-level compensation based on API orchestration to ensure that in a complex process involving multiple APIs, even if some API calls fail, they can be restored to the consistent state of the transaction through the rollback mechanism. In any case, the atomicity of the entire orchestration process can be achieved, that is, either all succeed or all rollback, thereby ensuring the integrity of the business process and the consistency of the data. In addition, this method realizes efficient execution and intelligent retry of API calls by introducing a dual thread pool mechanism of an execution engine and a retry engine. When an exception is detected, the task is automatically switched to the retry engine, and the execution strategy is dynamically adjusted based on the retry result, and the retry and exception handling are optimized to improve the robustness and success rate of the system. Moreover, this method simplifies the design and maintenance of complex processes through automated and intelligent orchestration and rollback mechanisms, reduces the error rate, and improves development efficiency. Moreover, compared with many related technologies that fail to fully consider the combination of business logic and orchestration processes, resulting in limited adaptability and effectiveness of solutions in actual application scenarios, this method allows the definition of business rules, such as specific rollback conditions, at the time of registration, which makes the orchestration more flexible, can more accurately match business needs, and improve the practical value and practicality of the overall solution. Not only that, this method can automatically identify and handle abnormal situations through built-in intelligent decision-making logic, reducing the need for manual intervention and thus improving work efficiency. At the same time, due to the simplification of process design and the introduction of automation mechanisms, the maintenance cost of the system can be significantly reduced in the long run. Moreover, given the emphasis on atomicity in this method, it naturally strengthens data integrity and security, which is particularly important for highly regulated industries. At the same time, the intelligent rollback mechanism helps to prevent potential violations at the data level and enhance compliance.

[0067] In an exemplary embodiment, as shown in FIG2 , based on the pre-stored target metadata of each target application programming interface API that needs to be arranged, the specific process of generating the execution task queue of the target API includes the following steps:

[0068] Step 201 : determining an API calling sequence based on pre-stored target metadata of each target API that needs to be arranged.

[0069] In an embodiment of the present application, the API call sequence can be process data. The target metadata may include request parameters and response parameters, and may also include one or more of context information, a Uniform Resource Locator (URL), and a calling method. The response parameter may include an identity document (ID). Context information, also known as upper and lower parameters and context fields, referred to as context, is a context field that needs to be persisted in the orchestration process, and is used for process status tracking to ensure the continuity of the process status. The calling method is the calling method of the API.

[0070] Step 202: Organize the API call sequence into a first-in-first-out queue to obtain an execution task queue of the target API.

[0071] In the embodiment of the present application, the execution task queue is used to indicate the execution order of the target API. The execution task queue may include a blocking execution flag attached to each task. The task is to call the API.

[0072] In the above-mentioned method for arranging application programming interfaces, based on the pre-stored target metadata of each target API to be arranged, the API call sequence is determined, and the API call sequence is organized into a first-in-first-out queue to obtain the execution task queue of the target API. In this way, the execution task queue of the target API is generated, which can clearly indicate the execution sequence and dependency relationship of the target API, and can improve the success rate of the execution of complex task processes composed of multiple APIs.

[0073] In an exemplary embodiment, as shown in FIG3 , in the case where there is a target API call failure, the method further includes the following steps:

[0074] Step 301: If the number of retries of the target API is less than a preset retry threshold and does not satisfy a preset rollback rule, the target API is re-called.

[0075] In the embodiment of the present application, the rollback rule can be a target API call failure, for example, the target API call at the end of the execution task queue fails. If the number of retries of the target API is less than the preset retry threshold and does not meet the preset rollback rule, the terminal calls the target API again and records the retry status of this re-call in the upper and lower information.

[0076] Step 302: If the number of retries of the target API reaches a preset retry threshold or satisfies a rollback rule, it is determined that a preset rollback condition is satisfied.

[0077] In an embodiment of the present application, if the number of retries of the target API reaches a preset retry threshold or satisfies a rollback rule, the terminal determines that the preset rollback condition is met and executes step 103.

[0078] In one example, if the retry status indicates that the target API is successfully re-called, the terminal continues to call each uncalled target API in sequence according to the execution task queue.

[0079] In the above-mentioned method for arranging application programming interfaces, in the case of a target API call failure, if the number of retries of the target API is less than the preset retry threshold and does not meet the preset rollback rules, the target API is re-called; if the number of retries of the target API reaches the preset retry threshold or meets the rollback rules, it is determined that the preset rollback conditions are met. In this way, when the target API call fails, the number of retries is less than the threshold, and the rollback rules are not met, the target API call is retried, which can improve the success rate of the execution of complex task processes composed of multiple APIs; when the target API call fails, but the number of retries is too many or the rollback rules are met, no retries are performed, and the rollback mechanism is triggered, and relative atomicity is achieved through the retry and compensation API calls. In addition, related technologies often require users to manually write complex retry logic and rollback processes, which not only increases the development burden, but also easily introduces errors. This method automatically handles retries and rollbacks through the intelligent linkage of the execution engine and the retry engine, greatly simplifies the process design, and reduces the error rate.

[0080] In an exemplary embodiment, the method further includes the following steps: if there is a rollback API call failure, re-calling the rollback API according to a preset rollback retry condition until the rollback API call is completed.

[0081] In the embodiment of the present application, the rollback API corresponds to the target API and the operation is opposite. For example, the target API is the cloud host activation API, and its corresponding rollback API is the cloud host destruction API. The order of the target APIs corresponding to the rollback API in the rollback task queue is opposite to the order of the target APIs in the execution task queue.

[0082] In one example, if the rollback API call is completed, the terminal continues to call the uncalled rollback APIs in sequence according to the rollback task queue.

[0083] In the above-mentioned orchestration method of the application programming interface, if there is a rollback API call failure, the rollback API is called again according to the preset rollback retry conditions until the rollback API call is completed. In this way, when the rollback API call fails, the rollback API call is retried to ensure that the rollback process can be executed to completion, ensuring that in a complex process involving multiple APIs, even if some API calls fail, they can be restored to the consistent state of the transaction through the rollback mechanism, and the atomicity of the entire orchestration process can be achieved in any case, that is, either all succeed or all rollback, thereby ensuring the integrity of the business process and the consistency of the data.

[0084] In an exemplary embodiment, as shown in FIG4 , the method further includes the following steps:

[0085] Step 401: When calling an API, write the first resource ID of a generated resource or the second resource ID of a destroyed resource into context information.

[0086] Among them, API includes target API and calling API.

[0087] In an embodiment of the present application, when the target API is called, the first resource ID of the generated resource is written into the context information. When the rollback API is called, the second resource ID of the destroyed resource is written into the context information. Conversely, when the target API is called, the second resource ID of the destroyed resource is written into the context information. When the rollback API is called, the first resource ID of the generated resource is written into the context information.

[0088] Step 402: When each target API call is completed or each rollback API call is completed, the process integrity information and data consistency information of the current call are determined according to the final state and context information of the current call.

[0089] The final state includes creation information or destruction information corresponding to each resource.

[0090] In an embodiment of the present application, the process integrity information is used to indicate whether the business process composed of each target API is complete, and the data consistency information is used to indicate whether the data in the business process processing composed of each target API is consistent.

[0091] In the above-mentioned API orchestration method, whether the execution is completed normally or the rollback process is completed, the final state and context information will be recorded, which can further ensure the integrity of the process and the consistency of the data. In addition, this method achieves efficient, secure and consistent management of the cloud computing resource life cycle through modular design, dynamic orchestration, intelligent execution and retry, decision and rollback mechanism and detailed logging. It is especially suitable for large-scale and high-concurrency cloud environments, and greatly improves the automation and reliability of resource management.

[0092] In an exemplary embodiment, as shown in FIG5 , the method further includes the following steps:

[0093] Step 501, when calling an API, record the API calling operation information.

[0094] The API includes the target API and the calling API. The calling operation information includes the request parameters, response results, retry records and rollback operations.

[0095] Step 502: determine audit information and / or troubleshooting information based on the call operation information.

[0096] In the embodiment of the present application, the audit information is used to indicate the audit result of the business process composed of each target API. The troubleshooting information is used to indicate the troubleshooting result of the business process composed of each target API.

[0097] In the above-mentioned API orchestration method, all execution details, retry records, and rollback operations will be recorded to facilitate subsequent auditing and troubleshooting, which can further improve the success rate of the execution of complex task processes composed of multiple APIs.

[0098] In one embodiment, the above-mentioned method for arranging an application programming interface can be applied to an orchestration system for an application programming interface, which includes: a registration module, an orchestration module, a calling module and a rollback module. The orchestration module may include: a decision engine and a distribution engine, and may also include an orchestration engine. The orchestration module is used to design and plan the execution process of the API based on the information provided by the registration module. The execution process of the API includes determining the execution order, dependencies and how to handle abnormal situations of the API. The working result of the orchestration module is to generate a detailed execution plan to guide the subsequent execution process. The calling module may include: a first execution engine and a first retry engine. The first execution engine is responsible for calling the API according to the execution plan generated by the orchestration module and managing the reading and writing of context parameters. The first retry engine intervenes when an execution failure occurs, tries to re-execute the failed API, and updates the retry status in the context for the orchestration module to make the next decision. The rollback module is similar to the execution module, and the rollback module may include: a second execution engine and a second retry engine. When the orchestration process fails, the orchestration module will reversely build the execution task of the rollback API. The rollback module calls the rollback API in the opposite order of the forward execution to undo the executed operations and restore the system state. In this way, this method realizes the separation of orchestration and compensation through modular design and simplified data structure, which can reduce the mutual influence. In addition, this method optimizes resource allocation, improves the system's concurrent processing capability and overall performance, and ensures the high reliability and stability of the service through the separation design of the execution engine and the retry engine, and the application of a multi-level compensation mechanism.

[0099] The system performs registration module initialization. Specifically, the system receives and stores the target metadata of each target application programming interface API to be orchestrated and the rollback metadata of the rollback API corresponding to each target API through the registration module. The target metadata includes: calling method, URL, request parameters and response parameters. The system also defines context fields through the registration module, defining the context fields that need to be persisted in the orchestration process to ensure the continuity of the process state. The system also receives and stores the retry conditions of API calls and the judgment conditions for triggering rollback (i.e., rollback conditions) through the registration module, providing a decision basis for process control. This stage is the foundation of the entire system, ensuring that subsequent orchestration and execution (i.e., API calls) have a basis to rely on. In this way, the registration module allows the definition of specific business rules, such as rollback conditions, so that the orchestration process can closely fit the actual business needs and enhance the practicality and flexibility of the system.

[0100] In the case where the orchestration module does not include an orchestration engine, the system uses the orchestration module to design the execution order and conditions of API calls based on registration information, creates process data, and organizes them into a FIFO queue form. In the case where the orchestration module includes an orchestration engine, the system uses the orchestration engine to design the execution order and conditions of API calls based on registration information, creates process data, and organizes them into a FIFO queue form. Then, the system distributes the first API call task to the first execution engine of the calling module through the distribution engine. The orchestration module includes a decision engine and a distribution engine, which are used to monitor the execution results and make the next decision.

[0101] After the first execution engine receives the task, the system calls the specified API and reads and writes the context parameters through the first execution engine. If the API call fails, the system transfers the task to the first retry engine through the orchestration module, executes the retry logic, and records the retry status in the context field for reference by the decision engine. The system decides whether to continue execution, retry again, or start the rollback process based on the retry result through the decision engine. If the decision engine determines that the current process has failed, the rollback mechanism is triggered. In the case where the orchestration module includes an orchestration engine, the system uses the orchestration engine to reversely construct a rollback API task list and prepare to roll back the process. Then, the system starts to execute the rollback API through the second execution engine included in the rollback module, and retries for failures in the rollback process through the second retry engine included in the rollback module until all rollback operations are completed.

[0102] Whether the execution is completed normally or the rollback process is completed, the system will record the final status and context information to ensure the integrity of the process and the consistency of the data. In addition, the system will also record all execution details, retry records and rollback operations for later auditing and troubleshooting.

[0103] In this way, this method creates an efficient, reliable, flexible and easy-to-maintain API orchestration system. Through its multi-level compensation mechanism, unique modular architecture and intelligent process control, it significantly improves the efficiency and reliability of API orchestration, provides strong technical support for complex business scenarios, realizes atomic orchestration of API calls, and ensures data consistency and smooth execution of business processes.

[0104] In one embodiment, the above method can be applied to an orchestration system of an application programming interface, the system comprising: a registration module, an orchestration module, a call module and a rollback module. The call module may include: a first execution engine and a first retry engine. The rollback module may include: a second execution engine and a second retry engine. The orchestration module may include: a decision engine and a distribution engine.

[0105] The system performs registration module initialization. Specifically, the system registers the metadata of the cloud host API through the registration module, that is, records the target metadata of the cloud host activation API (including request parameters such as the central processing unit (CPU), memory specifications, and response parameters such as the host ID) and the rollback metadata of the cloud host destruction API (including the host ID as a parameter). The system registers the metadata of the cloud hard disk API through the registration module, that is, registers the target metadata of the cloud hard disk activation API (including request parameters such as capacity, mounting host ID, and response parameters such as hard disk ID) and the rollback metadata of the cloud hard disk destruction API (including hard disk ID as a parameter). The system registers the metadata of the security group API through the registration module, that is, registers the target metadata of the security group activation API (including request parameters such as the rule list, response parameters such as the security group ID) and the rollback metadata of the security group destruction API (including the security group ID as a parameter). The system registers the metadata of the elastic public network IP (Elastic IP, EIP) API through the registration module, that is, registers the target metadata of the EIP activation API (including request parameters such as bandwidth, response parameters such as EIP address) and the rollback metadata of the EIP destruction API (including EIP address as a parameter). The system also defines context fields through the registration module for process status tracking. The context fields include host ID, hard disk ID, security group ID, and EIP address. The system also defines the number of retries and conditions for triggering rollback when the API call fails through the registration module. For example, the rollback process is triggered if the cloud host fails to be activated.

[0106] Through the orchestration module, the system designs the activation process based on the registration information as follows: security group activation → EIP activation → cloud hard disk activation → cloud host activation. Through the orchestration module, the system organizes the task queue according to the activation process, that is, the above activation process (that is, the API call sequence) is organized into a FIFO queue, and each task is accompanied by a blocking execution mark. Through the orchestration module, the system also stores process data, that is, records the context information of each step of the API call, such as the generated resource ID. Then, the system performs initialization task distribution through the distribution engine, that is, distributes the first API task (security group activation) to the first execution engine of the calling module.

[0107] The system calls the security group activation API through the first execution engine, captures the response parameters, and writes the generated security group ID into the context information. The system distributes the EIP activation task to the first execution engine by calling the module's distribution engine. If the EIP activation fails, the system forwards the task to the first retry engine through the first execution engine. Then, the system retries according to preset conditions through the first retry engine. If the retry fails, the system evaluates whether to trigger the rollback process based on the retry status through the decision engine.

[0108] If the decision engine confirms that the rollback process is triggered, the system will build a rollback task queue in reverse order through the orchestration module (i.e., cloud host destruction → cloud hard disk destruction → EIP destruction → security group destruction). Then, the system will start executing the rollback API through the second execution engine of the rollback module and destroy the corresponding resources according to the context information. If a failure occurs during the rollback process, the system will try to retry according to the set conditions through the second retry engine.

[0109] Whether the activation is successful or the rollback is completed, the system will record the final status, including the creation or destruction of all resources. The system also records the details of all API calls, including request parameters, response results, retry records and rollback operations, to facilitate later auditing and troubleshooting.

[0110] In this way, through the above steps, the atomic API orchestration system of this method ensures that the activation and destruction operations of cloud computing resources can maintain consistency and atomicity under any circumstances. Even if a partial failure occurs, it can be restored to the predetermined state through the rollback mechanism, avoiding potential risks in resource management and improving operation and maintenance efficiency and the security of resource management.

[0111] It should be understood that, although the various steps in the flowcharts involved in the above-mentioned embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-mentioned embodiments can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0112] Based on the same inventive concept, the embodiment of the present application also provides an application programming interface arrangement device for implementing the application programming interface arrangement method involved above. The implementation solution provided by the device to solve the problem is similar to the implementation solution recorded in the above method, so the specific limitations in the embodiment of the arrangement device of one or more application programming interfaces provided below can refer to the limitations of the arrangement method of the application programming interface above, and will not be repeated here.

[0113] In an exemplary embodiment, as shown in FIG6 , an application programming interface arrangement device 600 is provided, comprising: a generation module 610, a first calling module 620, a construction module 630 and a second calling module 640, wherein:

[0114] A generating module 610, configured to generate an execution task queue of each target application programming interface API that needs to be arranged based on pre-stored target metadata of the target API;

[0115] A first calling module 620, configured to call each of the target APIs in sequence according to the execution task queue;

[0116] A construction module 630 is used to construct a rollback task queue of the target API in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each target API if there is a target API call failure and the preset rollback condition is met;

[0117] The second calling module 640 is used to call the rollback API in sequence according to the rollback task queue until each rollback API call is completed.

[0118] Optionally, the generating module 610 is specifically configured to:

[0119] Determine the API call sequence based on pre-stored target metadata of each target application programming interface API that needs to be arranged;

[0120] The API call sequence is organized into a first-in-first-out queue to obtain an execution task queue of the target API.

[0121] Optionally, in the case where there is a target API call failure, the device 600 further includes:

[0122] A first recall module, configured to recall the target API if the number of retries of the target API is less than a preset retry threshold and does not satisfy a preset rollback rule;

[0123] The first determination module is used to determine whether a preset rollback condition is met if the number of retries of the target API reaches a preset retry threshold or satisfies the rollback rule.

[0124] Optionally, the device 600 further includes:

[0125] The second re-calling module is used to re-call the rollback API according to a preset rollback retry condition if there is a rollback API call failure until the rollback API call is completed.

[0126] Optionally, the device 600 further includes:

[0127] A writing module, used for writing the first resource ID of the generated resource or the second resource ID of the destroyed resource into the context information when calling an API; the API includes the target API and the calling API;

[0128] The second determination module is used to determine the process integrity information and data consistency information of this call according to the final state of this call and the context information when each target API call is completed or each rollback API call is completed; the final state includes the creation information or destruction information corresponding to each resource.

[0129] Optionally, the device 600 further includes:

[0130] A recording module, used to record the calling operation information of the API when calling the API; the API includes the target API and the calling API; the calling operation information includes request parameters, response results, retry records and rollback operations;

[0131] The third determination module is used to determine audit information and / or troubleshooting information according to the calling operation information.

[0132] Each module in the arrangement device of the above-mentioned application programming interface can be implemented in whole or in part by software, hardware or a combination thereof. Each of the above-mentioned modules can be embedded in or independent of the processor in the computer device in the form of hardware, or can be stored in the memory in the computer device in the form of software, so that the processor can call and execute the operations corresponding to each of the above modules.

[0133] In an exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be shown in FIG7. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. The processor, the memory, and the input / output interface are connected via a system bus, and the communication interface, the display unit, and the input device are connected to the system bus via the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal in a wired or wireless manner, and the wireless manner may be implemented through WIFI, a mobile cellular network, near field communication (NFC) or other technologies. When the computer program is executed by the processor, a method for arranging an application programming interface is implemented. The display unit of the computer device is used to form a visually visible picture, which may be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer device can be a touch layer covering the display screen, or a button, trackball or touchpad set on the computer device shell, or an external keyboard, touchpad or mouse.

[0134] Those skilled in the art will understand that the structure shown in FIG. 7 is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different arrangement of components.

[0135] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the steps in the above-mentioned method embodiments when executing the computer program.

[0136] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps in the above method embodiments are implemented.

[0137] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0138] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant regulations.

[0139] A person of ordinary skill in the art can understand that all or part of the processes in the above-mentioned embodiment method can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, an artificial intelligence (AI) processor, etc., but are not limited to this.

[0140] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0141] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A method for arranging an application programming interface, characterized in that: The method comprises: Based on pre-stored target metadata of each target application programming interface API that needs to be arranged, generating an execution task queue of the target API; According to the execution task queue, calling each of the target APIs in sequence; If there is a target API call failure and the preset rollback condition is met, then the rollback task queue of the target API is constructed in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each target API; According to the rollback task queue, the rollback APIs are called in sequence until each rollback API call is completed.

2. The method according to claim 1, characterized in that The step of generating an execution task queue of each target application programming interface API based on pre-stored target metadata of each target application programming interface API that needs to be arranged includes: Determine the API call sequence based on pre-stored target metadata of each target application programming interface API that needs to be arranged; The API call sequence is organized into a first-in-first-out queue to obtain an execution task queue of the target API.

3. The method according to claim 1, characterized in that: In the event that a target API call fails, the method further includes: If the number of retries of the target API is less than a preset retry threshold and does not meet the preset rollback rule, then re-call the target API; If the number of retries of the target API reaches a preset retry threshold, or satisfies the rollback rule, it is determined that the preset rollback condition is met.

4. The method according to claim 1, characterized in that: The method further comprises: If there is a rollback API call failure, the rollback API is called again according to the preset rollback retry conditions until the rollback API call is completed.

5. The method according to claim 1, characterized in that The method further comprises: When calling an API, writing the first resource ID of the generated resource or the second resource ID of the destroyed resource into context information; the API includes the target API and the calling API; When each of the target API calls is completed or each of the rollback API calls is completed, the process integrity information and data consistency information of this call are determined according to the final state of this call and the context information; the final state includes the creation information or destruction information corresponding to each resource.

6. The method according to claim 1, characterized in that The method further comprises: When calling an API, recording the calling operation information of the API; the API includes the target API and the calling API; the calling operation information includes request parameters, response results, retry records and rollback operations; Audit information and / or troubleshooting information is determined based on the call operation information.

7. An application programming interface arrangement device, characterized in that: The device comprises: A generation module, used for generating an execution task queue of each target application programming interface API that needs to be arranged based on pre-stored target metadata of the target API; A first calling module, used for calling each of the target APIs in sequence according to the execution task queue; A construction module, configured to construct a rollback task queue of the target API in reverse order based on the pre-stored rollback metadata of the rollback API corresponding to each of the target APIs if a target API call fails and the preset rollback condition is met; The second calling module is used to call the rollback API in sequence according to the rollback task queue until each rollback API call is completed.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images