API (Application Program Interface) calling method and system and related product

Abstract

The embodiment of the invention discloses an API calling method and system and a related product, and the method comprises the steps: generating a connection configuration interface and a login logic script for a target system based on a configuration parameter name needed for docking the target system; performing an assignment test on the login logic script by configuring a specific parameter value corresponding to the parameter name; wherein the successfully tested login logic script is used for triggering the target system to return identity credential information; and writing a calling logic script about the service API based on the identity credential information and request parameter information required by calling the service API. According to the method, specific parameter values required for docking a target system can be prompted in a guided manner, and a learning curve of a local system is reduced; in addition, the automatically generated login logic script can assist the local system to obtain identity credential information, so that the service function requesting the target system resource can be opened to the local system for self-definition, and the diversified calling requirements of the user on the business API resources of different target systems are met.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of application technology, and in particular to API calling methods, systems, and related products. Background Art

[0002] Application Programming Interface (API) is a set of predefined functions that aims to provide applications and developers with the ability to access routines (such as data, services and other resources) based on certain software or hardware without having to access the source code or understand the details of the internal working mechanism.

[0003] At present, the API tools on the market can help users connect to the business APIs of some external systems, but these API tools are pre-set by suppliers, and the business APIs that can be normally accessed and called are limited. In addition, when the number of APIs that need to be registered (or connected) by a user system increases, this API tool also finds it difficult to quickly register APIs in batches, resulting in an inability to efficiently meet the user's project integration needs. Summary of the invention

[0004] The embodiments of the present application provide an API calling method, system and related products for quickly registering and calling a system API.

[0005] A first aspect of an embodiment of the present application provides an API calling method, which is applied to a local system, including:

[0006] Determine the configuration parameter names required for docking with the target system;

[0007] Based on the configuration parameter name, generating a connection configuration interface and a login logic script for the target system;

[0008] Receiving a specific parameter value corresponding to the input configuration parameter name based on a prompt of the connection configuration interface;

[0009] The login logic script is assigned a value test by using the specific parameter value; wherein the login logic script that has been successfully tested is used to trigger the target system to return identity credential information, and the identity credential information is used to indicate that the local system is allowed to call the business API of the target system;

[0010] Based on the identity credential information and the request parameter information required to call the business API, a calling logic script for the business API is written.

[0011] Optionally, the determining of the configuration parameter name required for docking the target system includes:

[0012] The configuration parameter names required for connecting to the target system are parsed from the login document opened by the target system.

[0013] Optionally, after the target system returns the identity credential information, the method further includes:

[0014] The connection configuration interface and login logic script for the target system are exported as offline resources, so that after the system environment imports the offline resources, the permission to call the business API of the target system is also obtained through the received specific parameter values; the system environment includes the business modules within the local system and / or other systems except the local system.

[0015] Optionally, after the target system returns the identity credential information, the method further includes:

[0016] If the local system successfully calls the business API through the calling logic script, and the system environment also needs to call the business API, the calling logic script about the business API will be imported into the system environment, so that the system environment triggers the return of new identity credential information by reusing the offline resources, and fine-tunes the calling logic script to match the system environment.

[0017] Optionally, if there are multiple business APIs to be called, the method further includes:

[0018] At least logically arrange the calling order of the multiple business APIs;

[0019] For each business API belonging to different target systems, at least the step of determining the configuration parameter name required for docking the target system is performed according to the logic arrangement result, until a calling logic script for the business API is written.

[0020] Optionally, after writing the calling logic script for the business API, the method further includes:

[0021] Monitor the calling status of the service API, and if the calling status is a call failure, check the reason why the service API failed to be called;

[0022] If the reason is that the calling logic script of the business API is written incorrectly, the login logic script corresponding to the business API is assigned a test again, and / or the request parameter information required to call the business API is adjusted until the business API is successfully called or the number of retries to write the calling logic script of the business API reaches a preset number.

[0023] When the method described in the first aspect of the present application is implemented, the content described in the second aspect of the present application can be adopted to achieve it.

[0024] A second aspect of an embodiment of the present application provides an API calling system, including: a determination unit and a processing unit;

[0025] The determining unit is used to determine the configuration parameter name required for docking with the target system;

[0026] The processing unit is used to generate a connection configuration interface and a login logic script for the target system based on the configuration parameter name;

[0027] The processing unit is further configured to receive a specific parameter value corresponding to the input configuration parameter name based on a prompt of the connection configuration interface;

[0028] The processing unit is further used to perform a value assignment test on the login logic script through the specific parameter value; wherein the login logic script that has been successfully tested is used to trigger the target system to return identity credential information, and the identity credential information is used to indicate that the local system is allowed to call the business API of the target system;

[0029] The processing unit is also used to write a calling logic script about the business API based on the identity credential information and the request parameter information required to call the business API.

[0030] A third aspect of an embodiment of the present application provides an electronic device, including: a processor and a memory;

[0031] The processor is configured to communicate with the memory and execute instructions in the memory to implement the method described in the first aspect of the embodiment of the present application or any specific implementation of the first aspect.

[0032] A fourth aspect of an embodiment of the present application provides a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed by a processor, they implement the method described in the first aspect of the embodiment of the present application or any specific implementation of the first aspect.

[0033] A fifth aspect of an embodiment of the present application provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, they implement the method described in the first aspect of the embodiment of the present application or any specific implementation of the first aspect.

[0034] It can be seen from the above technical solutions that the embodiments of the present application have at least the following advantages:

[0035] The connection configuration interface generated in a targeted manner in the embodiment of the present application can provide a wizard-like prompt of the specific parameter values ​​required for docking with the target system, thereby reducing the learning curve of the local system. In addition, the automatically generated login logic script can assist the local system in obtaining identity credential information, so that the service functions for requesting target system resources can be opened to the local system for customization, thereby meeting the user's on-site diversified calling requirements for business API resources of different target systems and improving the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0037] It should be noted that, although the steps in the process diagrams (if any) involved in the embodiments are drawn in sequence as indicated by the arrows, unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the embodiments may 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 sequential, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0038] Figure 1 A schematic diagram of a system architecture of the API calling method according to an embodiment of the present application;

[0039] Figure 2 A flowchart of the API calling method according to an embodiment of the present application;

[0040] Figure 3 Another flowchart of the API calling method according to the embodiment of the present application;

[0041] Figure 4 A connection configuration interface diagram of the API calling method of the embodiment of the present application;

[0042] Figure 5 A schematic diagram of a set of API arrangement for the API calling method of an embodiment of the present application;

[0043] Figure 6 A schematic diagram of resource opening of the API calling method according to an embodiment of the present application;

[0044] Figure 7 A schematic diagram of the structure of the API calling system of the embodiment of the present application;

[0045] Figure 8 A schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0047] The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims and drawings of the present application are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0048] In the following description, similar expressions such as "a specific implementation" or "a specific example" are involved, which describe a subset of all possible embodiments, but it can be understood that "a specific implementation" or "a specific example" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict. In the following description, the term multiple refers to at least two. In some specific examples, the numerical value mentioned in this application reaches the threshold value (if any), which may include the case where the former is greater than the latter of the threshold value; if similar expressions such as "any" or "at least one" are mentioned, it can specifically refer to any one of the listed examples or any combination of these examples.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0050] See also Figure 1 , Figure 1Schematic diagram of the network equipment environment (or system architecture diagram) applicable in the implementation process of this application. In the implementation process of the technical solution provided in this application, the network equipment environment used includes but is not limited to the server 101, multiple computer nodes 102, 103 and 104. Of course, the number of computer nodes can also be customized, such as set to 1.

[0051] During use, server 101 can provide services for computer nodes 102, 103 and 104, and server 101 has functions such as responding to service requests of computer nodes, transmitting data, verifying computer node identities, etc. Server 101 can be a single network server, a server group composed of multiple network servers, or a cloud server composed of a large number of hosts or network servers based on cloud computing. Computer nodes 102, 103 and 104 are devices used by users, such as smart phones, tablet computers, laptops, desktop computers, PDAs, mobile internet devices (mobile internet devices, MID), wearable devices (such as smart watches, smart bracelets, etc.), smart computers, smart car-mounted and other intelligent terminals. Users can use the computer node to send corresponding service request instructions so that server 101 sends corresponding data to the computer node, thereby supporting the computer node to provide services for users.

[0052] In the embodiment of the present application, the local system of any computer node (such as 102) can determine the configuration parameter name required for docking with the target system (such as the operating system of server 101), and based on this configuration parameter name, generate a connection configuration interface and a login logic script for the target system; afterwards, the local system can receive a prompt based on the connection configuration interface, the specific parameter value corresponding to the input configuration parameter name, and assign this specific parameter value to the login logic script for assignment testing, and the login logic script that has been successfully tested can trigger the target system to return identity credential information, and the identity credential information is used to indicate that the local system is allowed to call the business API of the target system; the local system can write a call logic script about the business API based on the identity credential information and the request parameter information required to call the business API. Finally, the local system or the computer node where the local system is located can run the above-mentioned call logic script to request normal access to the resources associated with the business API, thereby completing the integration requirements of the project.

[0053] It should be noted that the method provided in the embodiment of the present application can be implemented jointly by a computer node and a server as described above, or it can be implemented entirely on the server side, or it can be implemented entirely on the computer node side. The specific method can be determined according to the actual application scenario and is not limited here.

[0054] The method of the present application will be further described in detail below, and some specific possible implementation examples will be provided. In actual applications, the implementation contents between these examples can be combined or implemented separately as needed according to the corresponding functional principles and application logic. If implemented in combination, the execution order between the combined examples can be determined according to their respective processing logics, which may be determined by the actual scenario.

[0055] See also Figure 2 In a first aspect, the present application provides a specific embodiment of an API calling method, which can be applied to a local system. The embodiment includes the following steps:

[0056] Step S21, determining the configuration parameter name required for docking the target system;

[0057] The above-mentioned target system can be called an external system relative to the local system. The target system opens at least one business API for the local system to call. Generally, the target system needs to be registered (or docked) to the local system first, that is, the local system must be able to log in to the target system normally, so that the local system can successfully call the business API of the target system later. Therefore, it is necessary to first determine the configuration parameter name required for docking the target system. In actual situations, the configuration parameter names required by different docking systems are usually different. For example, system a may require a user name, user password, uniform resource locator (URL) parameters of system a, etc., while system b may require the application identifier app id of the business application (APP, APPlication), application key app secret, URL of system b, etc.

[0058] Step S22: Generate a connection configuration interface and a login logic script for the target system based on the configuration parameter name;

[0059] For example, a connection configuration interface and a login logic script may be generated, both of which include configuration parameter names. The rendering style of this connection configuration interface (or login configuration interface) may include: a space for filling in specific parameter values ​​after the parameter name, error prompts for repeated or overlong content, etc., which may be set as needed and are not limited here. The above login logic script may be regarded as a login program, which is used to help the local system log in to the target system normally, thereby obtaining the right to call the business API of the target system.

[0060] Step S23, receiving a prompt based on the connection configuration interface, and a specific parameter value corresponding to the input configuration parameter name;

[0061] As described above, you can enter the corresponding specific parameter value according to the configuration parameter name prompted by the connection configuration interface. The specific parameter value can be assigned to the login logic script to debug this login logic script; the input here can be directly entered manually by the user or marked as certain parameter names required for the configuration of the interface, or the local system can automatically retrieve pre-stored specific parameter values ​​for corresponding input.

[0062] Step S24, performing assignment test on the login logic script through specific parameter values;

[0063] The successfully tested login logic script is used to trigger the target system to return the identity credential information, which is used to indicate that the local system is allowed to call the target system's business API. In other words, the successful login logic script test indicates, on the one hand, that the results of the previous steps are correct, such as the correct input parameter values, and on the other hand, that the target system can be registered normally to the local system, that is, the two systems have successfully achieved docking and can communicate resources, such as the local system can log in normally and access the resources of the target system.

[0064] The above-mentioned business API can specifically be an API using different protocols such as WebAPI or SOAPAPI. Among them, WebAPI is a set of rules and protocol interfaces that define access to resources (such as data, services, etc.) on the network, usually communicating through HTTP or HTTPs protocol; SOAPAPI is an API interface based on the SOAP protocol (built on the HTTP protocol) and uses XML format to transmit messages.

[0065] Step S25: Write a calling logic script for the business API based on the identity credential information and the request parameter information required for calling the business API.

[0066] The API call script usually includes the logic of constructing and sending the API call request message, so the above call logic script may include the call request message about the business API.

[0067] Exemplarily, the above-mentioned identity credential information can be a token Token (such as JWT) assigned by the target system to the local system. The Token can transmit and prove the identity and authority of the requester. The Token can contain at least one metadata such as the issuer (iss), subject (sub, i.e., user ID), expiration time (exp), signature (signature, used to verify the integrity and authenticity of the Token), and can also contain at least one additional session information such as the user's role, authority, user name, email address, etc. This information can be carried and sent to an external system in subsequent call requests to prove the identity and authority of the local system or its user end, thereby allowing normal access to resources associated with the business API.

[0068] In summary, the connection configuration interface generated in a targeted manner in the embodiment of the present application can provide a wizard-like prompt of the specific parameter values ​​required for docking with the target system, thereby reducing the learning curve of the local system; in addition, the automatically generated login logic script can assist the local system in obtaining identity credential information, so that the service function of requesting target system resources can be opened to the local system for customization, thereby meeting the user's on-site diversified calling needs for business API resources of different target systems and improving the user experience.

[0069] Based on the above example descriptions, some specific possible implementation examples are provided below.

[0070] based on Figure 2 As an example content of, as a possible implementation mode, the specific implementation operation of the above step S21 may include: parsing the configuration parameter name required for docking with the target system from the login document opened by the target system.

[0071] In actual situations, the target system usually prepares a login document in advance, which records the names of the configuration parameters required to connect to the target system. In addition, some target systems can also open a login-class API (i.e., login API). Successful connection to the login API can be regarded as successful connection to the target system to which this login API belongs, that is, the target system is successfully registered to the local system, so that the local system has the authority to call the business class API (i.e., business API) of the target system. Therefore, it can be understood that the above-mentioned login document can be called a cURL command document about the login API, which is used to record the names of the configuration parameters required for successful connection to the login API; with the help of a (self-developed) cURL parser, at least one of the following configuration parameter names required for the message can be extracted from the cURL command document about the login API: URL, request header (such as app id, app secret), request body, response body, etc.

[0072] Of course, in some cases, the above configuration parameter names may not need to be parsed from the login document opened by the target system. For example, as another possible implementation method, the local system may independently summarize the configuration parameter names required for docking with the same target system from historical docking records (mainly historical successful records of docking with the same target system). Alternatively, an experienced developer may actively input the configuration parameter names required for docking with this target system. The above multiple possible implementation methods may be selected depending on the situation and are not limited here.

[0073] Similarly, the "request parameter information required for calling the business API" mentioned in step S25 can be parsed from the business API call example document (or the cURL command document of the business API) opened by the target system, or obtained by summarizing historical docking records, etc. The specific method can be selected according to the situation and is not limited here.

[0074] The connection configuration interface and login logic script generated as described above can constitute a connector. This connector can be regarded as a middleware for connecting and accessing business APIs, responsible for data transmission and conversion; the login, refresh session, and test logic of the same type of connector are generally the same, and the category of connectors can be divided according to the specific model of the target system, etc. Figure 3 As shown, taking WebAPI as an example, a WebAPI connector can be generated based on the configuration parameter name. This WebAPI connector can include a connection configuration interface (such as Figure 4 As shown in the figure, the login logic script may also include the identity credential information (such as session information) returned by the login logic script after the successful test; after that, the operation of the WebAPI resources of the target system may rely on the above-generated WebAPI connector implementation, for example, the identity credential information contained in the WebAPI connector may be referenced to generate a call logic script for the business API resources of the target system. Among them, the process of assigning a value to the login logic script can be regarded as the process of testing the connector.

[0075] As explained above, the local system can customize the connector to conveniently connect to the external target system (also called third-party system or external system) and call the business API resources of the target system. The following will mainly explain how to open the permission of "customizing the call of the business API resources of the target system" for external systems other than the above local system.

[0076] Therefore, based on Figure 2 In some specific examples, after the target system returns the identity credential information, the method of the embodiment of the present application may also include: exporting the connection configuration interface and login logic script for the target system as offline resources, so that after the system environment imports the offline resources, it can also obtain the permission to call the business API of the target system through the received specific parameter values; the system environment includes business modules within the local system and / or other systems outside the local system.

[0077] Exemplarily, the local system a can obtain the identity credential information returned by the target system, which means that the connector generated for the target system can be recognized by the target system. Therefore, the related resources of this connector (such as the connection configuration interface and login logic script, etc.) can be exported as offline resources for the system environment to import and fine-tune these offline resources, and then successfully connect to the target system, so as to conveniently call the business API opened by the target system normally. In other words, the successfully tested connector can be directly exported as an offline resource, so as to be migrated and imported into other formal environments (i.e., the above-mentioned system environment). For example, the external system b does not need to repeatedly generate and test the connector, but directly changes the specific parameter value to the adjusted login logic script, so that the external system b can also successfully connect to the target system.

[0078] To put it more simply, if a certain type of system has been successfully connected in a certain customer system a, then after the related resources that facilitated this connection are exported, it can be directly imported and fine-tuned in another customer system b environment for use, thereby reducing the development workload of system b; this fine-tuning can be to change the original specific parameter value of the configuration parameter name (such as app id, app secret, etc.) of system a to the actual specific parameter value of this configuration parameter name of system b, that is, to achieve the best fit for each.

[0079] In some specific examples, if the business API to be called by the above-mentioned system environment and the local system is the same, you can choose to import the valid resources about the business API in the local system (such as the calling logic script about the business API, etc.) into the system environment in the same way to reduce the development workload of rewriting the calling logic script, etc. in the system environment. Therefore, as a possible implementation method, after the target system returns the identity credential information, the method of the embodiment of the present application may also include: if the local system successfully calls the business API by calling the logic script, and the system environment also wants to call the business API, then import the calling logic script about the business API into the system environment, so that the system environment triggers the return of new identity credential information by reusing offline resources, and fine-tunes the calling logic script that matches the system environment.

[0080] Similarly, in the process of migrating the API connector, the request parameter information required for calling the business API can be imported into the system environment, so that the system environment can fine-tune the existing call logic script, and then try to call the above business API, reducing the development cost and waiting time of the system environment using business API resources. The fine-tuning here can include: changing the identity credential information and request parameter information of system a in the call logic script to the identity credential information and request parameter information of system b, so as to adapt to the actual call requirements of system b.

[0081] In addition, in order to further reduce the investment cost of the system environment, the call logic script imported into the system environment can be a successfully tested script, for example, a call logic script that has been adjusted to enable the above-mentioned local system to successfully call the business API resource.

[0082] In short, in order to improve efficiency, you can quickly register connectors and WebAPIs by importing the content of the cURL command document, further simplifying the API integration process. Specifically, you can adjust the actual specific parameter information to perform online testing on connectors, WebAPIs and other resources; the developed and tested connectors, WebAPIs and other API model resources can be used as assets and quickly migrated and deployed to multiple system environments. Figure 6 As shown in the figure, the registered WebAPI can be called by other module microservices in the local system, and can also be published to the open platform for external system calls. It can be called by internal and external systems, realizing batch delivery and reuse of resources and reducing cost investment.

[0083] On the other hand, the export and import technologies such as Data Transmission Service (DTS) can be used to quickly migrate API model resources such as API connectors and request parameter information required to call business APIs. The above-mentioned DTS means that data can be read from one data source (such as an Excel file or Access database) and imported into another data source (such as a SQL Server database), and vice versa; this function makes it possible to read and write data in a common format between different applications, thereby realizing the process of data conversion.

[0084] based on Figure 2 In some specific examples, the calling process of multiple business APIs can be customized according to the actual project requirements: at least the calling sequence of multiple business APIs is logically arranged; for each business API belonging to a different target system, according to the logical arrangement results, at least the step of determining the configuration parameter name required for docking with the target system is executed separately, until the calling logic script for the business API is written.

[0085] For example, the following can be arranged: Figure 5The logical arrangement shown is to call the first business API first, and then call the second business API. This arrangement may be because the call of the second business API depends on the information returned by the first business API. Of course, the arrangement between multiple business APIs can be customized according to the needs and is not limited here. Afterwards, according to the logical arrangement results, operations such as steps S21 to S25 can be performed for each business API originating from different target systems until a call logic script is written for each business API. Among them, some repeated operations between multiple business APIs can be selectively ignored. For example, business APIs originating from the same target system can only perform one round of repeated operations such as steps S21 and S22 in total to reduce repeated workload. Of course, the specific situation can be determined.

[0086] On the other hand, the above-mentioned open logic orchestration function is flexible and reliable, which makes it easy to quickly and accurately discover abnormal business APIs in business APIs and improve the ability to deal with abnormal situations.

[0087] based on Figure 2 The example content, as a possible implementation method, can provide real-time monitoring and logging functions to facilitate tracking the status and performance of API calls. Therefore, after step S25, the method of the embodiment of the present application may also include: monitoring the call status of the business API, if the call status is a call failure, checking the reason why the business API failed to be called; if the reason is that the call logic script of the business API is written incorrectly, then again performing an assignment test on the login logic script corresponding to the business API, and / or adjusting the request parameter information required to call the business API until the business API is successfully called or the number of times the call logic script of the business API is retried reaches a preset number.

[0088] In other words, in order to improve the ability to deal with abnormal situations, a retry mechanism can be provided to allow the aforementioned business API that failed to be called to regain the opportunity to be called, so as to ensure that the actual needs of users are met. Exemplarily, a delay setting can be performed when the call fails. If multiple retries are required, multiple delays can be set and separated by commas, for example: [5 seconds, 30 seconds, 300 seconds] means a maximum of three retries, waiting for 5 seconds, 30 seconds, and 300 seconds respectively before retrying; or, a random waiting time can be set for each retry, for example: [(Math.random(50)+10)] seconds means generating at least one random waiting time between 10 and 60 seconds.

[0089] As a possible implementation method, if the reason for the above call failure is that the target system to which the business API belongs performs traffic control on the call request of the business API, the call logic script for the business API can be re-run after the traffic control is lifted. This traffic control can be that if the target system can only support a maximum of n API call requests within 1 second, the API call request message in the call logic script can be sent in the next 1 second to avoid wasting operating resources.

[0090] In short, you can control the flow of connectors or local systems, such as limiting the call frequency to avoid service overload or invalid waiting; you can also combine the integrated cloud service process to combine the orchestration API, and cooperate with the exception transfer and / or retry mechanism to improve the ability to deal with abnormal situations. Among them, the exception transfer can mean that if the retry fails after 3 times, a separate exception operation thread is expanded, such as initiating an exception reminder to the developer.

[0091] In summary, the embodiments of the present application provide an intuitive operating interface and visualization tools, which can realize the rapid registration of WebAPI connectors and WebAPIs and complete test verification, reduce the user's learning curve, and enable users to customize the development of API connection functions to meet the complex and changing needs of customers on site. The registered WebAPI can be called by other module microservices in the local system, and can also be published to the open platform for external system calls; in other words, the registered WebAPI, as a reusable offline resource, can not only flexibly arrange APIs through integrated service processes to meet changing needs, but also be delivered in batches to other system environments for resource integration needs. In addition, the embodiments of the present application provide error handling and retry mechanisms to ensure that the system can operate normally in the event of an abnormal situation.

[0092] In short, the embodiment of the present application provides a low-code fast registration WebAPI connector and WebAPI integration technology, which can significantly reduce the time and complexity of API integration. The technology includes fast registration of WebAPI according to cURL, fast configuration of connector parameters, and efficient API integration service flow, which is characterized by improving the efficiency and accuracy of API integration through automation and intelligent means.

[0093] Compared to Figure 2 The examples shown illustrate that the above-mentioned additional or detailed example contents or possible implementation methods do not necessarily have to be executed during the specific implementation. If more than two examples or possible implementation methods are added, these examples or possible implementation methods can be implemented in combination or separately. If implemented in combination, the execution order between the combined examples can be determined according to their respective processing logic, which can be determined according to the actual scenario.

[0094] See also Figure 7, the second aspect of the present application provides a specific embodiment of an API calling system, the system comprising: a determination unit 701, a processing unit 702;

[0095] The determination unit 701 is used to determine the configuration parameter name required for docking with the target system;

[0096] The processing unit 702 is used to generate a connection configuration interface and a login logic script for the target system based on the configuration parameter name;

[0097] The processing unit 702 is further configured to receive a specific parameter value corresponding to the input configuration parameter name based on a prompt of the connection configuration interface;

[0098] The processing unit 702 is further used to perform a value assignment test on the login logic script through specific parameter values; wherein the login logic script that has been successfully tested is used to trigger the target system to return identity credential information, and the identity credential information is used to indicate that the local system is allowed to call the business API of the target system;

[0099] The processing unit 702 is further configured to write a calling logic script for the business API based on the identity credential information and the request parameter information required for calling the business API.

[0100] In some examples, the determining unit 701 is specifically configured to:

[0101] Parse the configuration parameter names required for connecting to the target system from the login document opened by the target system.

[0102] In some examples, the processing unit 702 is further configured to:

[0103] Export the connection configuration interface and login logic script for the target system as offline resources, so that after the system environment imports the offline resources, it can also obtain the permission to call the business API of the target system through the received specific parameter values;

[0104] The system environment includes business modules within the local system and / or other systems outside the local system.

[0105] In some examples, the processing unit 702 is further configured to:

[0106] If the local system successfully calls the business API by calling the logic script, and the system environment also needs to call the business API, the calling logic script about the business API will be imported into the system environment, so that the system environment can trigger the return of new identity credential information by reusing offline resources, and fine-tune the calling logic script to match the system environment.

[0107] In some examples, the processing unit 702 is further configured to:

[0108] If there are multiple business APIs to be called, at least perform logical arrangement on the calling order of the multiple business APIs;

[0109] For each business API belonging to different target systems, according to the logic arrangement result, at least the step of determining the configuration parameter name required for connecting to the target system is performed respectively until a calling logic script for the business API is written.

[0110] In some examples, the processing unit 702 is further configured to:

[0111] Monitor the calling status of the business API. If the calling status is failed, check the reason why the business API failed to call.

[0112] If the reason is that the calling logic script of the business API is written incorrectly, the login logic script corresponding to the business API is assigned a test again, and / or the request parameter information required to call the business API is adjusted until the business API is successfully called or the number of retries to write the calling logic script of the business API reaches a preset number.

[0113] In the embodiment of the present application, the operations performed by each unit of the API calling system are similar to the operations described in the first aspect or any specific method embodiment of the first aspect, and will not be described in detail here. Of course, the specific implementation process of each operation in the first aspect of the present application can also refer to the relevant description of the second aspect.

[0114] See also Figure 8 The electronic device 800 of the embodiment of the present application may include one or more processors (such as central processing units (CPU)) 801 and a memory 805, in which one or more applications or data are stored.

[0115] The memory 805 may be a volatile storage or a persistent storage. The program stored in the memory 805 may include one or more modules, each of which may include a series of instruction operations in the electronic device. Furthermore, the processor 801 may be configured to communicate with the memory 805 and execute a series of instruction operations in the memory 805 on the electronic device 800.

[0116] The electronic device 800 may also include one or more power supplies 802, one or more wired or wireless network interfaces 803, one or more input and output interfaces 804, and / or one or more operating systems, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0117] The processor 801 can execute the operations performed by the aforementioned first aspect or any specific method embodiment of the first aspect, and the details will not be repeated here.

[0118] The present application provides a computer-readable storage medium, comprising instructions, which, when executed on a computer, enable the computer to execute the method described in the first aspect or any specific implementation of the first aspect.

[0119] The present application provides a computer program product comprising instructions or a computer program. When the computer program product is run on a computer, the computer is enabled to execute the method described in the first aspect or any specific implementation of the first aspect.

[0120] It is understood that in various embodiments of the present application, the sequence number of each step does not mean the order of execution, and the execution order of each step should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The operation content added or refined in each example scheme of the above method, system or device (if any) does not necessarily have to be executed in the specific implementation. If more than two operations are added, these operations can be implemented in combination or separately, depending on the actual scenario.

[0121] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system (if any) and device described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0122] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system or device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0123] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0124] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0125] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product. The computer software product (or computer program product) is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a business server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.

Claims

1. An API calling method, characterized in that: Applies to local systems, including: Determine the configuration parameter names required for docking with the target system; Based on the configuration parameter name, generating a connection configuration interface and a login logic script for the target system; Receiving a specific parameter value corresponding to the input configuration parameter name based on a prompt of the connection configuration interface; The login logic script is assigned a value test by using the specific parameter value; wherein the login logic script that has been successfully tested is used to trigger the target system to return identity credential information, and the identity credential information is used to indicate that the local system is allowed to call the business API of the target system; Based on the identity credential information and the request parameter information required to call the business API, a calling logic script for the business API is written.

2. The API calling method according to claim 1, characterized in that: The determining of the configuration parameter name required for docking the target system includes: The configuration parameter names required for connecting to the target system are parsed from the login document opened by the target system.

3. The API calling method according to claim 1, characterized in that: After the target system returns the identity credential information, the method further includes: Export the connection configuration interface and login logic script for the target system as offline resources, so that after the system environment imports the offline resources, it can also obtain the permission to call the business API of the target system through the received specific parameter values; The system environment includes business modules within the local system and / or other systems except the local system.

4. The API calling method according to claim 3, characterized in that: After the target system returns the identity credential information, the method further includes: If the local system successfully calls the business API through the calling logic script, and the system environment also needs to call the business API, the calling logic script about the business API will be imported into the system environment, so that the system environment triggers the return of new identity credential information by reusing the offline resources, and fine-tunes the calling logic script to match the system environment.

5. The API calling method according to claim 1, characterized in that: If there are multiple business APIs to be called, the method further includes: At least logically arrange the calling order of the multiple business APIs; For each business API belonging to different target systems, at least the step of determining the configuration parameter name required for docking the target system is performed according to the logic arrangement result, until a calling logic script for the business API is written.

6. The API calling method according to claim 1 or 5, characterized in that: After writing the calling logic script for the business API, the method further includes: Monitor the calling status of the service API, and if the calling status is a call failure, check the reason why the service API failed to be called; If the reason is that the calling logic script of the business API is written incorrectly, the login logic script corresponding to the business API is assigned a test again, and / or the request parameter information required to call the business API is adjusted until the business API is successfully called or the number of retries to write the calling logic script of the business API reaches a preset number.

7. An API calling system, characterized in that: include: Determine the unit and process the unit; The determining unit is used to determine the configuration parameter name required for docking with the target system; The processing unit is used to generate a connection configuration interface and a login logic script for the target system based on the configuration parameter name; The processing unit is further configured to receive a specific parameter value corresponding to the input configuration parameter name based on a prompt of the connection configuration interface; The processing unit is further used to perform a value assignment test on the login logic script through the specific parameter value; wherein the login logic script that has been successfully tested is used to trigger the target system to return identity credential information, and the identity credential information is used to indicate that the local system is allowed to call the business API of the target system; The processing unit is also used to write a calling logic script about the business API based on the identity credential information and the request parameter information required to call the business API.

8. An electronic device, characterized in that: include: Processor and memory; The processor is configured to communicate with the memory and execute instructions in the memory to implement the method according to any one of claims 1 to 6.

9. A readable storage medium, characterized in that: The readable storage medium stores computer instructions, and when the computer instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, characterized in that The computer program product comprises computer instructions, and when the computer instructions are executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images