Application program interface calling method and device based on block chain

Abstract

The invention discloses an application program interface calling method and device based on a block chain. The method relates to the field of block chains, and comprises the following steps: receiving a calling request initiated by a calling party, extracting calling parameters in the calling request, generating calling metadata based on the calling parameters, and uploading the calling metadata to the block chain; under the condition that the security verification of the calling metadata on the block chain is passed, extracting interface calling preference information of a calling party from a target knowledge graph of the block chain; inputting the calling metadata, the interface calling preference information and the target knowledge graph into a target model to obtain a recommended target application program interface and a calling path of the target application program interface; and calling the target application program interface through the calling path to provide service for the calling party. Through the method and the device, the problem of security risk existing in application program interface calling in related technologies is solved.

Description

Technical Field

[0001] This application relates to the field of blockchain, and more specifically, to a method and apparatus for calling application programming interfaces (APIs) based on blockchain. Background Technology

[0002] With the sweeping wave of digitalization, APIs (Application Programming Interfaces) have become a key link connecting distributed systems, playing a central role, especially in cross-organizational data sharing. APIs enable different software systems to communicate and exchange data in a standardized manner, greatly promoting the interconnectivity and flexibility of the software ecosystem.

[0003] However, the API call process in related technologies relies on centralized gateways for management. In dynamic and cross-organizational scenarios, this centralized management approach lacks transparent call records and reliable evidence storage mechanisms, resulting in insufficient security for data during transmission and interaction. The lack of call records and the uncertainty of call results make the call process difficult to trace, and the completeness and authenticity of the results cannot be verified.

[0004] There is currently no effective solution to the security risks associated with application programming interface (API) calls in related technologies. Summary of the Invention

[0005] The main purpose of this application is to provide a blockchain-based application programming interface (API) invocation method and apparatus to address the security risks associated with API invocation in related technologies.

[0006] To achieve the above objectives, according to one aspect of this application, a blockchain-based application programming interface (API) invocation method is provided. The method includes: receiving a call request initiated by a caller; extracting call parameters from the call request; generating call metadata based on the call parameters; and uploading the call metadata to the blockchain. The call request contains description information of the API that the caller needs to invoke, and the call parameters indicate the data type and data format returned by the API. If the call metadata passes security verification on the blockchain, the method extracts the caller's API invocation preference information from a target knowledge graph of the blockchain. The target knowledge graph consists of N nodes and M edges, where each node represents an API or a caller, and each edge represents the invocation relationship between APIs, or the caller's historical invocation records of APIs, where N and M are positive integers. The method inputs the call metadata, API invocation preference information, and target knowledge graph into a target model to obtain a recommended target API and a call path for the target API. Finally, the method invokes the target API through the call path to provide services to the caller.

[0007] Optionally, inputting the call metadata, interface call preference information, and target knowledge graph into the target model to obtain the recommended target application interface and the call path of the target application interface includes: processing the call metadata and interface call preference information through the interface matching module of the target model to obtain the target application interface; filtering out P candidate call paths of the target application interface from the target knowledge graph through the call path filtering module of the target model, where P is a positive integer; calculating the recommendation evaluation value of each candidate call path through the path recommendation module of the target model, and determining the candidate call path corresponding to the maximum recommendation evaluation value as the call path of the target application interface.

[0008] Optionally, the recommended evaluation value of each candidate call path is calculated by the path recommendation module of the target model, including: for each candidate call path, determining the call cost, historical call success rate, and performance indicators of the candidate call path, wherein the performance indicators include at least one of the following: response time and resource consumption; determining the first weight of the call cost, the second weight of the historical call success rate, and the third weight of the performance indicators; and performing a weighted summation of the call cost, historical call success rate, and performance indicators based on the first weight, the second weight, and the third weight to obtain the recommended evaluation value of the candidate call path.

[0009] Optionally, after providing services to the caller by calling the target application interface through the call path, the method further includes: receiving the call result of the target application interface and extracting the actual result hash value from the call result; comparing the actual result hash value with the expected hash value in the blockchain to obtain a comparison result, wherein the expected hash value is obtained by hash calculation based on the expected call result of the call metadata; uploading the call result to the blockchain if the comparison result indicates that the data is complete and the security verification is passed; and issuing a prompt message if the comparison result indicates that the data is incomplete or the security verification is failed, wherein the prompt message is used to prompt the caller to switch to an alternative application interface.

[0010] Optionally, after providing services to the caller by invoking the target application interface through the call path, the method further includes: determining the call volume data and call complexity data of the call path, wherein the call volume data includes at least one of the following: the data transmission volume of the call path and the number of calls to each application interface in the call path, and the call complexity data includes at least one of the following: computational resource consumption and the number of application interface calls; calculating the call cost of the call request based on the call volume data and call complexity data; and uploading the call cost and the call request record to the blockchain.

[0011] Optionally, the target knowledge graph is obtained as follows: The call logs of Q application interfaces of a financial institution are obtained; the dependencies between application interfaces and the call records of callers to application interfaces are extracted from the call logs, where Q is less than N and Q is a positive integer; each application interface is identified as a node, and the caller that calls the application interface is identified as a node, resulting in N nodes; edges are connected between nodes corresponding to two application interfaces with dependencies, and edges are connected between the node corresponding to the caller associated with the call record and the node corresponding to the application interface, resulting in M ​​edges; the target knowledge graph is constructed from the N nodes and M edges.

[0012] Optionally, the method further includes: when a financial institution deploys a new application programming interface (API), converting the new API into a new node and adding the new node to the target knowledge graph; collecting API call records every preset period and updating the target knowledge graph based on the call records.

[0013] To achieve the above objectives, according to another aspect of this application, a blockchain-based application programming interface (API) invocation device is provided. The device includes: a receiving unit, configured to receive an invocation request initiated by a caller, extract invocation parameters from the invocation request, generate invocation metadata based on the invocation parameters, and upload the invocation metadata to the blockchain, wherein the invocation request contains description information of the API to be invoked by the caller, and the invocation parameters indicate the data type and data format returned by the API to be invoked; an extraction unit, configured to extract the caller's interface invocation preference information from a target knowledge graph of the blockchain, provided that the invocation metadata has passed security verification on the blockchain, wherein the target knowledge graph consists of N nodes and M edges, each node representing an API or a caller, and each edge representing the invocation relationship between APIs, or the caller's historical invocation records of APIs, where N and M are positive integers; an input unit, configured to input the invocation metadata, interface invocation preference information, and target knowledge graph into a target model to obtain a recommended target API and an invocation path for the target API; and a service unit, configured to provide services to the caller by invoking the target API through the invocation path.

[0014] In this embodiment, a call request initiated by the caller is received, call parameters are extracted from the call request, call metadata is generated based on the call parameters, and the call metadata is uploaded to the blockchain. The call request contains description information of the application interface to be called by the caller, and the call parameters indicate the data type and data format returned by the application interface to be called. If the call metadata passes security verification on the blockchain, the caller's interface call preference information is extracted from the target knowledge graph of the blockchain. The target knowledge graph consists of N nodes and M edges. Each node represents an application interface or a caller, and each edge represents the call relationship between application interfaces, or the caller... For historical call records of application programming interfaces (APIs), where N and M are positive integers; call metadata, API call preference information, and target knowledge graph are input into the target model to obtain recommended target APIs and their call paths; by calling the target APIs through the call paths to provide services to the callers, the decentralized and trusted mechanism of blockchain ensures the transparency and immutability of API call records. By using the target knowledge graph and target model to recommend target APIs and call paths to the callers, the goal of secure API calls is achieved, thereby improving the technical effect of improving the security of API calls and solving the technical problem of security risks in API calls. Attached Figure Description

[0015] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a blockchain-based application programming interface (API) calling method is shown. Figure 2 This is a flowchart of a blockchain-based application programming interface (API) invocation method provided in the embodiments of this application; Figure 3 This is a schematic diagram of a blockchain-based application programming interface (API) calling system provided according to an embodiment of this application; Figure 4 This is a schematic diagram of a blockchain-based application programming interface (API) calling device according to an embodiment of this application; Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0016] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0018] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0019] Example 1 According to an embodiment of this application, a method embodiment for calling a blockchain-based application programming interface is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a blockchain-based application programming interface (API) calling method is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, processing devices such as MCU (Microcontroller Unit) or FPGA (Field-Programmable Gate Array), memory 104 for storing data, and transmission device 106 for communication functions. In addition, it may also include: a display, input / output interfaces (I / O interfaces), a USB (Universal Serial Bus) port (which may be included as one of the ports of a BUS (Business Bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0021] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0022] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the blockchain-based application interface calling method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned blockchain-based application interface calling method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0023] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0024] The display may be, for example, a touchscreen LCD display that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0025] In the above operating environment, this application provides a blockchain-based application programming interface (API) invocation method. Figure 2 This is a flowchart of a blockchain-based application programming interface (API) invocation method provided according to an embodiment of this application, such as... Figure 2 As shown, the method includes: Step S201: Receive the call request initiated by the caller, extract the call parameters from the call request, generate call metadata based on the call parameters, and upload the call metadata to the blockchain. The call request contains the description information of the application interface that the caller needs to call, and the call parameters are used to indicate the data type and data format returned by the application interface that needs to be called.

[0026] In step S201, blockchain is a distributed ledger technology that records data in a decentralized manner, linking blocks in a chain structure to form an immutable, transparent, and traceable data storage system. Blockchain is used to store application programming interface (API) call records to ensure the security and traceability of API calls. An API defines the rules and protocols for how software applications interact and communicate with each other. It allows different software systems or components to exchange data and call functions without exposing their internal implementations. APIs provide a set of predefined functions, methods, or operations, enabling developers to access and use the functionality of other applications or services in a simplified way.

[0027] The API gateway or server receives a call request from the caller. The request contains descriptions of the API the caller needs to invoke, such as the API name, version, and function description. The call parameters are parsed and extracted from the request. Call parameters are specific instructions that guide the API on how to process the request, including but not limited to data type, data format, operation type, and specific parameter content. The call parameters are checked to ensure they conform to the API's expected format requirements, including data type and format correctness verification, to ensure the API can process these parameters correctly. Based on the extracted call parameters, call metadata is constructed. Call metadata includes, but is not limited to, the caller's ID, call time, the API name and version, and the expected type and format of the returned data. Before uploading the call metadata to the blockchain, a security verification is performed to confirm the data is correct and the caller's permissions are valid. The call metadata is then uploaded to the blockchain, leveraging the blockchain's immutability to provide a trusted and tamper-proof record of the call process.

[0028] Step S202: If the security verification of the calling metadata on the blockchain is passed, extract the caller's interface calling preference information from the target knowledge graph of the blockchain. The target knowledge graph consists of N nodes and M edges. Each node is used to represent an application interface or a caller. Each edge is used to represent the calling relationship between application interfaces, or the caller's historical call records to application interfaces. N and M are positive integers.

[0029] In step S202, a knowledge graph is a structured way of representing knowledge. It constructs a semantic network through nodes and edges, visually displaying entities (such as people, places, and things) and their relationships. It connects information in the form of a graph, giving data context and semantic understanding, helping machines better process and reason about complex problems. Through the consensus mechanism and hash verification of the blockchain, the integrity and tamper-proof nature of the called metadata are ensured. Only after the called metadata is successfully verified on the blockchain will the target application programming interface be recommended to the caller.

[0030] After the blockchain security verification is passed, the caller's API call preference information is extracted from the target knowledge graph. This preference information may include the caller's most frequently used APIs, the call frequency of specific APIs, the success rate of calls, and the call duration. By analyzing the caller's preferences and the call relationships between APIs, the call path is intelligently optimized to ensure that the call process is efficient and meets the caller's expectations. For example, the order of API calls can be adjusted to avoid using APIs with long response times or frequent failures.

[0031] Step S203: Input the call metadata, interface call preference information and target knowledge graph into the target model to obtain the recommended target application interface and the call path of the target application interface.

[0032] In step S203, the collected call metadata, call preference information, and target knowledge graph are used as input and fed into the target model for analysis. The target model can be a machine learning model, a deep learning model, or a rule-based recommendation system. Based on the input information, the target model analyzes the caller's preferences and recommends the target application programming interface (API) that best meets the user's needs. The model considers factors such as call history, API performance, and call cost to generate the optimal recommendation. While recommending APIs, the model also analyzes the call relationships between APIs and generates one or more call paths to achieve the most efficient service call. The target model outputs the recommended target application programming interfaces and their call paths.

[0033] Step S204: Provide services to the caller by calling the target application interface through the call path.

[0034] In step S204, the target application interfaces are invoked sequentially according to the selected call path. This may involve calling multiple APIs to complete a complex service request. In the call path, the result returned by one API may need to be used as a parameter for the next API call. The system automatically handles the transmission of these parameters to ensure data consistency and correctness. As the call path is executed, the target application interfaces provide the caller with the required services, such as data querying, updating, and calculation operations.

[0035] The blockchain-based application interface (API) invocation method provided in this application embodiment receives an invocation request initiated by a caller, extracts invocation parameters from the request, generates invocation metadata based on the parameters, and uploads the metadata to the blockchain. The invocation request includes a description of the API that the caller needs to invoke, and the invocation parameters indicate the data type and format returned by the API. After the invocation metadata passes security verification on the blockchain, the caller's API invocation preference information is extracted from the blockchain's target knowledge graph. This target knowledge graph consists of N nodes and M edges, where each node represents an API or a caller, and each edge represents the interaction between APIs. Using relationships, or historical call records of the caller to the application programming interface (API), where N and M are positive integers; inputting call metadata, API call preference information, and the target knowledge graph into the target model, we obtain recommended target APIs and their call paths; providing services to the caller by calling the target API through the call path; and ensuring the transparency and immutability of API call records through the decentralized and trusted mechanism of blockchain. By using the target knowledge graph and target model to recommend target APIs and call paths to the caller, we achieve the goal of secure API calls, thereby improving the technical effect of API call security and solving the technical problem of security risks in API calls.

[0036] To more accurately provide the required application programming interfaces (APIs) to the caller, a target model is used to recommend target APIs and call paths to the caller. Optionally, in the blockchain-based API calling method provided in this application embodiment, inputting call metadata, interface call preference information, and target knowledge graph into the target model to obtain the recommended target API and the call path of the target API includes: processing the call metadata and interface call preference information through the interface matching module of the target model to obtain the target API; filtering P candidate call paths for the target API from the target knowledge graph through the call path filtering module of the target model, where P is a positive integer; calculating the recommendation evaluation value of each candidate call path through the path recommendation module of the target model, and determining the candidate call path corresponding to the maximum recommendation evaluation value as the call path of the target API.

[0037] In some embodiments, the latest call metadata of the caller, including call time, call parameters, and call frequency, is extracted from the blockchain. Based on the target knowledge graph on the blockchain, the caller's interface call preference information, such as the most frequently called API types, call success rate, and performance preferences, is extracted. The call metadata and interface call preference information are input into the interface matching module of the target model. This module analyzes the caller's needs and preferences, and filters the target application interface that best matches the caller's current needs from the registered APIs. Through the call path filtering module of the target model, P candidate call paths for the target application interface are filtered from the target knowledge graph. Based on the call relationships between APIs in the graph and the caller's historical call records, multiple possible call paths are generated for subsequent evaluation and selection.

[0038] The target model's path recommendation module calculates a recommended evaluation value for each candidate call path. The evaluation value can be based on factors such as path efficiency (e.g., total response time), stability (e.g., failure rate), and cost-effectiveness. The calculated recommended evaluation values ​​are compared, and the call path with the highest evaluation value is selected as the call path for the target application interface. This ensures that the caller can call the API through the optimized path, improving service efficiency and user experience.

[0039] This embodiment intelligently recommends target application interfaces and their calling paths based on the target model, calling metadata, interface calling preference information, and target knowledge graph, thereby achieving efficient, secure, and personalized API calling services. This improves service efficiency and user experience while ensuring the security and transparency of the calling process.

[0040] The recommended evaluation value can be determined by the call cost, historical call success rate, and performance indicators of the call path. Optionally, in the blockchain-based application interface call method provided in this application embodiment, the calculation of the recommended evaluation value of each candidate call path by the path recommendation module of the target model includes: for each candidate call path, determining the call cost, historical call success rate, and performance indicators of the candidate call path, wherein the performance indicators include at least one of the following: response time and resource consumption; determining a first weight for the call cost, a second weight for the historical call success rate, and a third weight for the performance indicators; and performing a weighted sum of the call cost, historical call success rate, and performance indicators based on the first weight, the second weight, and the third weight to obtain the recommended evaluation value of the candidate call path.

[0041] In some embodiments, a first weight is determined for call cost, a second weight for historical call success rate, and a third weight for performance metrics. These weights reflect the importance of different characteristics of the call path in the final evaluation value. Weight values ​​can be based on caller preferences, system presets, or dynamically adjusted. For each candidate call path, the call cost is determined. Call cost may include direct financial costs, API call fees, data transfer costs, etc. The historical call records of the APIs in the candidate call paths are analyzed to calculate the call success rate. Response time can be the average time required for the API to process a request and return a response. Resource consumption can be the computational, network, and storage resources required to call the API, etc. Based on the defined weights, the call cost, historical call success rate, and performance metrics of each candidate call path are weighted and summed to calculate a recommended evaluation value.

[0042] This embodiment defines weights and collects comprehensive evaluation parameters. The weighted summation algorithm comprehensively considers call cost, historical call success rate, and performance indicators. Based on the caller's specific needs and the system's operating status, it dynamically adjusts the path selection strategy, effectively evaluating and optimizing candidate call paths. This improves the efficiency and success rate of API calls.

[0043] To ensure the accuracy of the call results, the actual call result hash value is compared with the expected hash value. Optionally, in the blockchain-based application interface call method provided in this application embodiment, after providing services to the caller by calling the target application interface through the call path, the method further includes: receiving the call result of the target application interface and extracting the actual result hash value from the call result; comparing the actual result hash value with the expected hash value in the blockchain to obtain a comparison result, wherein the expected hash value is obtained by hash calculation based on the expected call result of the call metadata; uploading the call result to the blockchain if the comparison result indicates that the data is complete and the security verification is passed; and issuing a prompt message if the comparison result indicates that the data is incomplete or the security verification is failed, wherein the prompt message is used to prompt the caller to switch to an alternative application interface.

[0044] In some embodiments, the system receives a call result returned by the target application interface, which contains the result of the data or operation requested by the caller. The actual result hash value is extracted from the call result. The actual result hash value is calculated using a hash algorithm on the call result data and is used for subsequent comparison with the expected hash value. The actual result hash value is compared with the expected hash value previously stored in the blockchain. The expected hash value is calculated using a hash algorithm based on the expected call result from the call metadata. If the actual result hash value matches the expected hash value, it indicates that the data is complete and has not been tampered with, and the security verification is successful. If the comparison result indicates that the data is complete and the security verification is successful, the call result and metadata are uploaded to the blockchain, forming an immutable call record, enhancing the system's transparency and trustworthiness. If the actual result hash value does not match the expected hash value, or the security verification fails, the data is considered incomplete or corrupted. In this case, the system issues a prompt message, suggesting that the caller try switching to an alternative application interface.

[0045] This embodiment effectively verifies the integrity and security of the API call result by comparing the actual hash value with the expected hash value. After the data integrity and security are verified, the call result is uploaded to the blockchain, which improves the transparency of the interface call. When encountering incomplete data or security verification failure, prompts are issued to guide the caller to take countermeasures (such as switching to alternative APIs) to ensure service continuity and data security.

[0046] After each application interface call, the call record is stored on the blockchain. Optionally, in the blockchain-based application interface calling method provided in this application embodiment, after providing services to the caller by calling the target application interface through the call path, the method further includes: determining the call volume data and call complexity data of the call path, wherein the call volume data includes at least one of the following: the data transmission volume of the call path and the number of calls to each application interface in the call path, and the call complexity data includes at least one of the following: computational resource consumption and the number of application interface calls; calculating the call cost of the call request based on the call volume data and call complexity data; and uploading the call cost and the call request record to the blockchain.

[0047] In some embodiments, the amount of data transmitted in the call path, including the size of request parameters and the size of return results, is measured to assess network transmission costs. The number of calls to each application programming interface (API) in the call path is counted to calculate API call costs. The computational resources consumed during the execution of the call path are assessed. The total number of API calls in the call path is calculated. Based on the collected call volume and call complexity data, combined with a pre-defined cost model (such as a linear model, non-linear model, etc.), the total call cost of the call request is calculated. Cost calculation may involve network transmission costs, computational resource costs, and API call count costs. The calculated call cost, along with basic information about the call request, is packaged into a transaction data block. The data block is uploaded to the blockchain via a smart contract module to ensure data transparency and immutability. Each transaction data block contains detailed information about the call cost and call request, thus providing the caller with a clear call record and cost breakdown.

[0048] This embodiment accurately assesses the total cost of API calls by precisely calculating the call volume and complexity data of the call path, and uses blockchain technology to achieve transparent storage of call costs and call records. This enhances the transparency and trust in the API call process within a distributed system.

[0049] To more accurately recommend target application interfaces to callers, a target knowledge graph needs to be constructed in advance. Optionally, in the blockchain-based application interface invocation method provided in this application embodiment, the target knowledge graph is obtained in the following way: obtain the invocation logs of Q application interfaces of a financial institution, extract the dependency relationships between application interfaces and the call records of callers to application interfaces from the invocation logs, where Q is less than N and Q is a positive integer; determine each application interface as a node and the caller that invokes the application interface as a node, resulting in N nodes; connect the nodes corresponding to two application interfaces with dependency relationships with edges, and connect the nodes corresponding to the callers associated with the invocation records with the nodes corresponding to the application interfaces with edges, resulting in M ​​edges; construct the target knowledge graph from the N nodes and M edges.

[0050] In some embodiments, call logs for Q application programming interfaces (APIs) are obtained from the financial institution's system. The dependencies between APIs are analyzed and extracted from the call logs. For example, API A may require data from API B as input before execution. Call records of APIs by callers are extracted, including call time, call frequency, and call parameters. Each API and caller are identified as a node in the graph, forming N nodes. Edges are connected between nodes based on dependencies and call records. If API A depends on API B, or caller C calls API A, an edge is established between the corresponding nodes, representing the relationship or call behavior between them. The target knowledge graph consists of N nodes and M edges, where M represents the total number of edges for all dependencies and call records. The construction process of the knowledge graph ensures the structure and semantics of the data, making the relationships between APIs and the behavioral patterns of callers readily apparent.

[0051] This embodiment constructs a detailed target knowledge graph that reflects the API call patterns and dependencies of financial institutions, providing data support for the input of the target model, thereby improving the efficiency and security of interface calls.

[0052] The target knowledge graph is updated in real time as the application programming interface (API) changes. Optionally, in the blockchain-based API calling method provided in this application embodiment, the method further includes: when a financial institution deploys a new API, converting the new API into a new node and adding the new node to the target knowledge graph; collecting API call records every preset period and updating the target knowledge graph based on the call records.

[0053] In some embodiments, when a financial institution deploys a new application programming interface (API), an API update process is automatically triggered. The newly added API is transformed into a new node in the target knowledge graph. This ensures the graph reflects the latest changes in the financial institution's API ecosystem in a timely manner. A preset period (e.g., daily, weekly, or real-time) is set to automatically collect API call records from the financial institution's API gateway or related logs. Call records may include caller ID, call time, API ID, parameter summary, call result hash, etc. If the call records reveal new dependencies, such as another API that was not called before a certain API started calling, the edges (representing dependencies) in the knowledge graph need to be updated accordingly. Based on the collected call records, caller preferences, frequency, and time patterns are analyzed, and the analyzed dependencies and call patterns are updated to the target knowledge graph to maintain the timeliness and accuracy of the graph information.

[0054] This embodiment enables financial institutions to accurately capture the dynamic changes in the API ecosystem and optimize API call paths and recommendation strategies by regularly collecting API call records and updating the knowledge graph in real time.

[0055] According to another embodiment of this application, a blockchain-based application programming interface (API) calling system is also provided. Figure 3 This is a schematic diagram of a blockchain-based application programming interface (API) calling system provided according to an embodiment of this application, such as... Figure 3 As shown, the system includes: a blockchain layer, a knowledge graph layer, and an API gateway layer.

[0056] Specifically, the blockchain layer provides trusted notarization and distributed trust mechanisms to ensure transparency and security throughout the entire API call lifecycle. The blockchain layer includes a call notarization module, a smart contract module, and a cross-chain interaction module. The call notarization module records API call metadata (such as caller, call time, parameter digest, call result hash, etc.) to ensure the immutability of the call process. It generates a unique call transaction ID for easy subsequent querying and traceability. The smart contract module defines call authorization, access control, and billing rules. It automates the processing of API call permission verification and fee settlement. The cross-chain interaction module supports the sharing of call records between different blockchains, ensuring data interoperability in multi-organizational collaboration scenarios.

[0057] The knowledge graph layer performs semantic modeling of APIs, callers, and call behavior, supporting intelligent recommendations and call path optimization. The knowledge graph layer includes an API semantic modeling module, a caller modeling module, an intelligent recommendation module, and a call chain analysis module. The API semantic modeling module constructs a knowledge graph of APIs, including API functional descriptions, parameter types, performance metrics, and call logs. It enables dynamic updates and classification management of APIs (e.g., automatic adjustment for added, modified, or expired APIs). The caller modeling module models the call behavior, needs, preferences, and historical call records of callers (users or systems). It establishes semantic associations between callers and APIs, improving matching efficiency. The intelligent recommendation module dynamically recommends optimal API service combinations based on semantic reasoning from the knowledge graph. The recommendation algorithm combines multiple dimensions such as user needs, service performance, and historical call success rates. The call chain analysis module analyzes the dependencies and performance bottlenecks of complex call chains, optimizing call paths. It supports dynamic reconstruction of call chains, improving call efficiency and success rates.

[0058] The API gateway layer is responsible for the actual call execution and dynamic optimization, connecting user needs with underlying services. It includes a dynamic routing module, a call result verification module, and a load balancing module. The dynamic routing module dynamically selects the optimal API call method based on the service path recommended by the knowledge graph. It supports multi-objective optimization (such as performance, cost, and security). The call result verification module verifies the integrity and trustworthiness of the API call results by comparing the call metadata stored on the blockchain with the hash value of the returned results. The load balancing module dynamically distributes request load based on blockchain call logs and knowledge graph performance analysis, avoiding single points of failure.

[0059] The execution flow of a blockchain-based application programming interface (API) call system is as follows: Users initiate a call request through the API gateway, carrying a description of their needs and call parameters. The gateway generates call metadata (initiator, timestamp, parameter summary) and stores it on the blockchain for trusted notarization. The gateway queries the knowledge graph to obtain recommended API service paths. Based on user needs, the knowledge graph matches suitable API services through semantic reasoning. Candidate API services are evaluated across multiple dimensions (e.g., performance, cost, success rate), and the optimal call path is recommended. The call chain analysis module dynamically optimizes the call order to avoid dependency bottlenecks. The API gateway completes the call according to the recommended path and receives the call result. The hash value of the call result is compared with the metadata stored on the blockchain to verify the integrity and trustworthiness of the data. If the call fails or verification fails, automatic retry or switching to a backup service is triggered. The smart contract automatically calculates fees based on call volume or complexity, completing dynamic settlement. Fees and call records are stored on the blockchain to ensure transaction transparency.

[0060] This embodiment of the blockchain-based application programming interface (API) call system combines blockchain technology with knowledge graphs to achieve trusted evidence storage, semantic modeling, and intelligent recommendation throughout the entire API call lifecycle. This improves the security, transparency, and efficiency of the call process and meets the needs of dynamic collaboration and intelligent service discovery in complex systems.

[0061] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0062] Example 2 This application also provides a blockchain-based application programming interface (API) invocation device. It should be noted that this blockchain-based API invocation device can be used to execute the blockchain-based API invocation method provided in this application. The following describes the blockchain-based API invocation device provided in this application.

[0063] According to an embodiment of this application, an apparatus for implementing the above-described blockchain-based application programming interface (API) invocation method is also provided. Figure 4 This is a schematic diagram of a blockchain-based application programming interface (API) calling device provided according to an embodiment of this application, such as... Figure 4 As shown, the device includes: The receiving unit 401 is used to receive a call request initiated by the caller, extract the call parameters in the call request, generate call metadata based on the call parameters, and upload the call metadata to the blockchain. The call request contains the description information of the application interface that the caller needs to call, and the call parameters are used to indicate the data type and data format returned by the application interface that needs to be called. Extraction unit 402 is used to extract the interface call preference information of the caller from the target knowledge graph of the blockchain after the security verification of the call metadata on the blockchain is passed. The target knowledge graph consists of N nodes and M edges. Each node is used to represent an application interface or a caller. Each edge is used to represent the call relationship between application interfaces, or the caller's historical call record of the application interface. N and M are positive integers. Input unit 403 is used to input call metadata, interface call preference information and target knowledge graph into the target model to obtain the recommended target application interface and the call path of the target application interface; Service unit 404 is used to provide services to the caller by invoking the target application interface through the call path.

[0064] The blockchain-based application interface calling device provided in this application embodiment receives a call request initiated by a caller through a receiving unit 401, extracts call parameters from the call request, generates call metadata based on the call parameters, and uploads the call metadata to the blockchain. The call request includes a description of the application interface to be called by the caller, and the call parameters indicate the data type and data format returned by the application interface to be called. The extraction unit 402, after the call metadata has passed security verification on the blockchain, extracts the caller's interface calling preference information from the target knowledge graph of the blockchain. The target knowledge graph consists of N nodes and M edges, where each node represents an application interface or a caller, and each edge represents the communication between application interfaces. Using a relation, or the historical call records of the caller to the application programming interface (API), where N and M are positive integers; input unit 403 inputs call metadata, API call preference information, and target knowledge graph into the target model to obtain recommended target APIs and their call paths; service unit 404 provides services to the caller by calling the target API through the call path. Through the decentralized and trusted mechanism of blockchain, the transparency and immutability of API call records are ensured. By using the target knowledge graph and target model to recommend target APIs and call paths to the caller, the purpose of secure API calls is achieved, thereby improving the technical effect of API call security and solving the technical problem of security risks in API calls.

[0065] Optionally, in the blockchain-based application interface calling device provided in this application embodiment, the input unit 403 includes: a first processing module, used to process call metadata and interface call preference information through the interface matching module of the target model to obtain the target application interface; a filtering module, used to filter out P candidate call paths of the target application interface from the target knowledge graph through the call path filtering module of the target model, where P is a positive integer; and a first calculation module, used to calculate the recommendation evaluation value of each candidate call path through the path recommendation module of the target model, and determine the candidate call path corresponding to the maximum recommendation evaluation value as the call path of the target application interface.

[0066] Optionally, in the blockchain-based application programming interface (API) calling device provided in this application embodiment, the first calculation module includes: a first determining submodule, used to determine the calling cost, historical calling success rate, and performance indicators of each candidate calling path, wherein the performance indicators include at least one of the following: response time and resource consumption; a second determining submodule, used to determine a first weight of the calling cost, a second weight of the historical calling success rate, and a third weight of the performance indicators; and a summing submodule, used to perform a weighted summation of the calling cost, historical calling success rate, and performance indicators based on the first weight, the second weight, and the third weight to obtain a recommended evaluation value for the candidate calling path.

[0067] Optionally, in the blockchain-based application interface calling device provided in this application embodiment, the device further includes: a hash extraction unit, used to receive the calling result of the target application interface and extract the actual result hash value from the calling result; a comparison unit, used to compare the actual result hash value with the expected hash value in the blockchain to obtain a comparison result, wherein the expected hash value is obtained by hash calculation based on the expected calling result of the calling metadata; a first upload unit, used to upload the calling result to the blockchain if the comparison result indicates that the data is complete and the security verification is passed; and a prompting unit, used to issue a prompting message if the comparison result indicates that the data is incomplete or the security verification is not passed, wherein the prompting message is used to prompt the caller to switch to an alternative application interface.

[0068] Optionally, in the blockchain-based application interface calling device provided in this application embodiment, the device further includes: a first determining unit, used to determine the call volume data and call complexity data of the call path, wherein the call volume data includes at least one of the following: the data transmission volume of the call path and the number of calls to each application interface in the call path, and the call complexity data includes at least one of the following: the consumption of computing resources and the number of application interface calls; a calculation unit, used to calculate the call cost of the call request based on the call volume data and the call complexity data; and a second uploading unit, used to upload the call cost and the record of the call request to the blockchain.

[0069] Optionally, in the blockchain-based application interface calling device provided in this application embodiment, the target knowledge graph is obtained in the following way: obtaining the calling logs of Q application interfaces of a financial institution, extracting the dependency relationships between application interfaces and the calling records of the calling party to the application interface from the calling logs, where Q is less than N and Q is a positive integer; determining each application interface as a node, determining the calling party that calls the application interface as a node, obtaining N nodes; connecting the nodes corresponding to two application interfaces associated with the dependency relationship with edges, connecting the nodes corresponding to the calling party associated with the calling record and the nodes corresponding to the application interface with edges, obtaining M edges; constructing the target knowledge graph from the N nodes and M edges.

[0070] Optionally, in the blockchain-based application interface calling device provided in the embodiments of this application, the device further includes: a conversion unit, used to convert the new application interface into a new node and add the new node to the target knowledge graph when the financial institution deploys the new application interface; and an update unit, used to collect the calling records of the application interface every preset period and update the target knowledge graph based on the calling records.

[0071] It should be noted that the receiving unit 401, extraction unit 402, input unit 403, and service unit 404 mentioned above correspond to steps S201 to S204 in Embodiment 1. The four units and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules or units can also be part of a device and run in the computer terminal 10 provided in Embodiment 1.

[0072] Example 3 Embodiments of this application may provide an electronic device. Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 5 As shown, the electronic device may include: one or more ( Figure 5 (Only one is shown) processor 502, memory 504, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0073] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0074] The processor can access information and applications stored in memory via a transmission device to perform the following steps: receiving a call request initiated by a caller, extracting call parameters from the call request, generating call metadata based on the call parameters, and uploading the call metadata to the blockchain. The call request contains a description of the application interface (API) that the caller needs to invoke, and the call parameters indicate the data type and format returned by the API. If the call metadata passes security verification on the blockchain, the processor extracts the caller's interface call preference information from the blockchain's target knowledge graph. The target knowledge graph consists of N nodes and M edges, where each node represents an API or a caller, and each edge represents the call relationship between APIs, or the caller's historical call records for APIs, where N and M are positive integers. The processor inputs the call metadata, interface call preference information, and target knowledge graph into the target model to obtain recommended target APIs and their call paths. Finally, the processor invokes the target APIs through the call paths to provide services to the caller.

[0075] The processor can also invoke information and applications stored in the memory via the transmission device to perform the following steps: process the call metadata and interface call preference information through the interface matching module of the target model to obtain the target application interface; filter P candidate call paths for the target application interface from the target knowledge graph through the call path filtering module of the target model, where P is a positive integer; calculate the recommendation evaluation value of each candidate call path through the path recommendation module of the target model, and determine the candidate call path corresponding to the maximum recommendation evaluation value as the call path of the target application interface.

[0076] The processor can also invoke information and applications stored in memory via a transmission device to perform the following steps: For each candidate call path, determine the call cost, historical call success rate, and performance metrics of the candidate call path, wherein the performance metrics include at least one of the following: response time and resource consumption; determine a first weight for the call cost, a second weight for the historical call success rate, and a third weight for the performance metrics; and perform a weighted summation of the call cost, historical call success rate, and performance metrics based on the first weight, the second weight, and the third weight to obtain a recommended evaluation value for the candidate call path.

[0077] The processor can invoke information and applications stored in memory via a transmission device to perform the following steps: receiving the call result of the target application interface and extracting the actual result hash value from the call result; comparing the actual result hash value with the expected hash value in the blockchain to obtain a comparison result, wherein the expected hash value is obtained by hash calculation based on the expected call result of the call metadata; uploading the call result to the blockchain if the comparison result indicates that the data is complete and the security verification is passed; and issuing a prompt message if the comparison result indicates that the data is incomplete or the security verification is failed, wherein the prompt message is used to prompt the caller to switch to an alternative application interface.

[0078] The processor can access information and applications stored in memory via a transmission device to perform the following steps: determining call volume data and call complexity data for a call path, wherein the call volume data includes at least one of the following: the amount of data transferred in the call path and the number of calls to each application interface in the call path, and the call complexity data includes at least one of the following: computational resource consumption and the number of application interface calls; calculating the call cost of the call request based on the call volume data and call complexity data; and uploading the record of the call cost and the call request to the blockchain.

[0079] The processor can access information and applications stored in memory via a transmission device to perform the following steps: Obtain call logs for Q application interfaces of a financial institution; extract the dependencies between application interfaces and the call records of callers to the application interfaces from the call logs, where Q is less than N and Q is a positive integer; define each application interface as a node and the caller that calls the application interface as a node, resulting in N nodes; connect edges between nodes corresponding to two application interfaces with dependencies, and connect edges between the node corresponding to the caller associated with the call record and the node corresponding to the application interface, resulting in M ​​edges; construct a target knowledge graph from the N nodes and M edges.

[0080] The processor can access information and applications stored in memory via a transmission device to perform the following steps: when a financial institution deploys a new application programming interface (API), the new API is converted into a new node and added to the target knowledge graph; the API call records are collected every preset period, and the target knowledge graph is updated based on the call records.

[0081] This application provides a method for receiving a call request initiated by a caller, extracting call parameters from the call request, generating call metadata based on the call parameters, and uploading the call metadata to a blockchain. The call request includes a description of the application interface (API) that the caller needs to invoke, and the call parameters indicate the data type and format returned by the API. If the call metadata passes security verification on the blockchain, the caller's API call preference information is extracted from the blockchain's target knowledge graph. The target knowledge graph consists of N nodes and M edges, where each node represents an API or a caller, and each edge represents the call relationship between APIs, or the caller's historical call records for APIs. N and M are positive integers. The call metadata, API call preference information, and target knowledge graph are input into a target model to obtain recommended target APIs and their call paths. Finally, a scheme is implemented to provide services to the caller by invoking the target APIs through these call paths. By leveraging the decentralized and trusted mechanism of blockchain, the transparency and immutability of application programming interface (API) call records are ensured. Target knowledge graphs and target models are used to recommend target APIs and call paths to callers, achieving the goal of secure API calls. This improves the security of API calls and solves the technical problem of security risks associated with API calls.

[0082] Those skilled in the art will understand that Figure 5 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 5 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 5 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 5 The different configurations shown.

[0083] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0084] Example 4 Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the blockchain-based application programming interface (API) invocation method provided in Embodiment 1.

[0085] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0086] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing blockchain-based application programming interface (API) call method steps.

[0087] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0088] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0089] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

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

[0091] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0092] If the integrated unit is implemented as 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 this application, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0093] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for calling an application programming interface (API) based on blockchain, characterized in that, include: The system receives a call request initiated by a caller, extracts the call parameters from the call request, generates call metadata based on the call parameters, and uploads the call metadata to the blockchain. The call request contains description information of the application interface that the caller needs to call, and the call parameters are used to indicate the data type and data format returned by the application interface that needs to be called. If the security verification of the call metadata on the blockchain is passed, the interface call preference information of the caller is extracted from the target knowledge graph of the blockchain. The target knowledge graph consists of N nodes and M edges. Each node is used to represent an application interface or a caller. Each edge is used to represent the call relationship between application interfaces, or the caller's historical call records to application interfaces. N and M are positive integers. The call metadata, the interface call preference information, and the target knowledge graph are input into the target model to obtain the recommended target application interface and the call path of the target application interface; The target application interface is invoked through the invocation path to provide services to the caller.

2. The method according to claim 1, characterized in that, By inputting the call metadata, the interface call preference information, and the target knowledge graph into the target model, the recommended target application interface and the call path of the target application interface are obtained, including: The target application interface is obtained by processing the call metadata and the interface call preference information through the interface matching module of the target model. The call path filtering module of the target model filters out P candidate call paths for the target application interface from the target knowledge graph, where P is a positive integer; The path recommendation module of the target model calculates the recommended evaluation value of each candidate call path, and determines the candidate call path corresponding to the maximum recommended evaluation value as the call path of the target application interface.

3. The method according to claim 2, characterized in that, The path recommendation module of the target model calculates the recommendation evaluation value for each candidate call path, including: For each candidate call path, determine the call cost, historical call success rate, and performance metrics of the candidate call path, wherein the performance metrics include at least one of the following: response time and resource consumption; Determine the first weight of the call cost, the second weight of the historical call success rate, and the third weight of the performance metric; The recommended evaluation value of the candidate call path is obtained by weighting and summing the call cost, the historical call success rate and the performance index based on the first weight, the second weight and the third weight.

4. The method according to claim 1, characterized in that, After providing services to the caller by invoking the target application interface through the invocation path, the method further includes: Receive the call result of the target application interface, and extract the actual result hash value from the call result; The actual result hash value is compared with the expected hash value in the blockchain to obtain a comparison result, wherein the expected hash value is obtained by hash calculation based on the expected call result of the call metadata; If the comparison results indicate that the data is complete and the security verification is successful, the call result will be uploaded to the blockchain. If the comparison result data is incomplete or the security verification fails, a prompt message is issued, which prompts the caller to switch to an alternative application interface.

5. The method according to claim 1, characterized in that, After providing services to the caller by invoking the target application interface through the invocation path, the method further includes: Determine the call volume data and call complexity data of the call path, wherein the call volume data includes at least one of the following: the data transmission volume of the call path and the number of calls to each application interface in the call path, and the call complexity data includes at least one of the following: computational resource consumption and the number of application interface calls; The call cost of the call request is calculated based on the call volume data and the call complexity data; The call cost and the call request record are uploaded to the blockchain.

6. The method according to claim 1, characterized in that, The target knowledge graph is obtained in the following way: Obtain the call logs of Q application interfaces of the financial institution, and extract the dependencies between application interfaces and the call records of the caller to the application interface from the call logs, where Q is less than N and Q is a positive integer; Each application interface is identified as a node, and the caller of the application interface is identified as a node, resulting in N nodes; Connect the nodes corresponding to the two application interfaces associated with the dependency relationship with an edge, and connect the node corresponding to the caller associated with the call record and the node corresponding to the application interface with an edge to obtain M edges; The target knowledge graph is constructed from the N nodes and the M edges.

7. The method according to claim 1, characterized in that, The method further includes: When a financial institution deploys a new application programming interface (API), the new API is converted into a new node, and the new node is added to the target knowledge graph. The application interface call records are collected at preset intervals, and the target knowledge graph is updated based on the call records.

8. A blockchain-based application programming interface (API) calling device, characterized in that, include: The receiving unit is used to receive a call request initiated by the caller, extract the call parameters in the call request, generate call metadata based on the call parameters, and upload the call metadata to the blockchain. The call request contains description information of the application interface that the caller needs to call, and the call parameters are used to indicate the data type and data format returned by the application interface that needs to be called. The extraction unit is used to extract the interface call preference information of the caller from the target knowledge graph of the blockchain when the security verification of the call metadata on the blockchain is passed. The target knowledge graph consists of N nodes and M edges. Each node is used to represent an application interface or a caller. Each edge is used to represent the call relationship between application interfaces, or the caller's historical call records to application interfaces. N and M are positive integers. The input unit is used to input the call metadata, the interface call preference information and the target knowledge graph into the target model to obtain the recommended target application interface and the call path of the target application interface; A service unit is used to provide services to the caller by invoking the target application interface through the call path.

9. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program executes the blockchain-based application programming interface invocation method according to any one of claims 1 to 7 when it runs.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the blockchain-based application programming interface invocation method as described in any one of claims 1 to 7.

Images