Application program interface recommendation method and related device

Abstract

The embodiment of the invention provides an application program interface recommendation method and a related device, and relates to the field of financial science and technology or other related fields, and the method comprises the steps: obtaining a business demand text of a user, and interface features of each application program interface in an application program interface library; processing the business demand text, and determining dominant demand characteristics of the user for the application program interface; hidden demand characteristics of the user for the application program interface are mined from the dominant demand characteristics, and target demand characteristics are determined based on the dominant demand characteristics and the hidden demand characteristics; and matching the target demand feature with the interface feature of the application program interface, and outputting a recommended application program interface. According to the method, the optimal interface or the interface combination can be screened out from massive APIs, so that the problems of fuzzy requirements, low interface screening efficiency and complex combinatorial logic in financial system docking are solved, and the user experience is effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of financial technology or other related fields, and in particular, to an application program interface screening method and related device. BACKGROUND

[0002] In the financial industry, the system docking requirements between large financial institutions and partners are increasingly complex and diversified. Partners usually describe their business requirements in natural language, but such requirements often have ambiguity and multi-level nature. At this time, the financial institution needs to screen out interfaces that match functions and adapt to performance from a large number of application program interfaces (APIs), or design an interface combination scheme to meet the requirements.

[0003] In the prior art, financial institutions usually rely on human experience to analyze requirements and screen interfaces, resulting in low efficiency and missing optimal solutions. SUMMARY

[0004] Embodiments of the present application provide an application program interface recommendation method and related device to improve the efficiency of application program interface screening and improve the quality of screening.

[0005] In a first aspect, embodiments of the present application provide an application program interface recommendation method, comprising:

[0006] obtaining a business requirement text of a user, and interface features of each application program interface in an application program interface library;

[0007] processing the business requirement text to determine explicit requirement features of the user for the application program interface;

[0008] mining implicit requirement features of the user for the application program interface from the explicit requirement features, and determining target requirement features based on the explicit requirement features and the implicit requirement features;

[0009] matching the target requirement features and the interface features of the application program interface, and outputting a recommended application program interface.

[0010] In some embodiments, the processing of the business requirement text to determine the explicit requirement features of the user for the application program interface comprises:

[0011] cleaning, tokenizing, and part-of-speech tagging the business requirement text to obtain a structured business requirement;

[0012] positioning key requirements from the structured business requirement based on part-of-speech tagging in the structured business requirement;

[0013] Based on the key requirements, at least one requirement document is selected from the requirement document library, and based on the standardized requirements corresponding to the requirement document, the explicit requirement characteristics are determined.

[0014] In some embodiments, the step of mining the user's implicit requirements for the application interface from the explicit requirements includes:

[0015] A target knowledge graph is obtained by performing low-dimensional vector mapping on a preset business knowledge graph; wherein, nodes in the business knowledge graph identify business entities, and edges represent the relationships between business entities;

[0016] Using the explicit demand features as known entities, relational path reasoning is performed on the explicit demand features in the target knowledge graph to obtain the implicit demand features.

[0017] In some embodiments, determining the target demand characteristics based on the explicit demand characteristics and the implicit demand characteristics includes:

[0018] The explicit and implicit demand features are combined to obtain a demand set.

[0019] Convert each requirement in the requirement set into a corresponding sub-vector;

[0020] The target requirement features are obtained by fusing the sub-vectors based on a preset fusion strategy.

[0021] In some embodiments, obtaining the interface characteristics of each application interface in the application interface library includes:

[0022] Obtain the interface parameters of the application interface; the interface parameters include basic information, parameter characteristics, call characteristics, and performance characteristics;

[0023] The basic information, parameter features, call features, and performance features are vectorized respectively to obtain the basic information vector, parameter vector, call vector, and performance feature vector of the application programming interface;

[0024] The basic information vector, the parameter vector, the call vector, and the performance feature vector are fused to obtain the features of the application programming interface.

[0025] In some embodiments, the basic information is vectorized to obtain the basic information vector of the application programming interface, including:

[0026] The basic information is encoded to obtain a semantic vector corresponding to the basic information;

[0027] The path hierarchy of the application interface is vectorized, and the vectors corresponding to each path hierarchy are merged to obtain the path vector of the application interface.

[0028] The semantic vector and the path vector are fused to obtain the basic information vector.

[0029] In some embodiments, matching the target requirement features and the interface features of the application interface to output a recommended application interface includes:

[0030] Obtain the similarity between the target requirement features and each of the interface features;

[0031] If there is an interface feature whose similarity meets the preset threshold, then the application interface corresponding to that interface feature is used as the recommended application interface.

[0032] If no interface feature has a similarity that meets the preset threshold, then the corresponding combination of application interfaces is selected from the multiple application interfaces, and the combination of application interfaces is used as the recommended application interface.

[0033] In some embodiments, the step of filtering corresponding application interface combinations from the plurality of application interfaces includes:

[0034] The target requirement features are broken down into multiple sub-requirements;

[0035] For each sub-requirement, the similarity between the sub-requirement and the interface features is obtained, and a candidate interface combination corresponding to the sub-requirement is obtained based on the similarity.

[0036] Based on the application interface call dependencies, the target interface combination is determined from the candidate interface combinations;

[0037] Based on preset combination evaluation rules, recommended application interface combinations are selected from the target interface combinations.

[0038] Secondly, the application programming interface (API) recommendation device includes:

[0039] The acquisition module is used to acquire the user's business requirement text, as well as the interface characteristics of each application interface in the application interface library.

[0040] The processing module is used to process the business requirement text based on a natural language model to determine the user's explicit requirement characteristics for the application interface.

[0041] The determination module is used to extract the user's implicit requirements for the application interface from the explicit requirements features, and to determine the target requirements features based on the explicit requirements features and the implicit requirements features.

[0042] The recommendation module is used to match the target requirement features with the interface features of the application interface and output a recommended application interface.

[0043] Thirdly, this application provides an electronic device, including: a memory and a processor;

[0044] The memory is used to store computer instructions; the processor is used to execute the computer instructions stored in the memory to implement the method of any one of the first aspects.

[0045] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the method of any of the first aspects.

[0046] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0047] The application programming interface (API) recommendation method and related apparatus provided in this application extract explicit requirements and mine implicit requirements of business needs, and based on feature matching technology, can select the optimal interface or combination of interfaces from a massive number of API interfaces, thereby solving the problems of ambiguous requirements, inefficient interface selection and complex combination logic in financial system integration, and effectively improving the user experience. Attached Figure Description

[0048] Figure 1 A scenario diagram provided for an embodiment of this application;

[0049] Figure 2 A flowchart illustrating an application programming interface (API) recommendation method provided in this application embodiment. Figure 1 ;

[0050] Figure 3 A flowchart illustrating an application programming interface (API) recommendation method provided in this application embodiment. Figure 2 ;

[0051] Figure 4 A schematic diagram of an application programming interface (API) recommendation device provided in this application embodiment;

[0052] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0053] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] In the embodiments of this application, the terms "first" and "second" are used to distinguish identical or similar items with essentially the same function and effect, without limiting their order. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that the terms "first" and "second" do not necessarily imply that they are different.

[0055] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0056] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all 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 the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0057] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0058] It should be noted that the application programming interface recommendation method and related apparatus provided in this application can be used in the field of fintech or other related fields, or in any field other than fintech or other related fields. This application does not limit the application field of the application programming interface recommendation method and related apparatus.

[0059] With the rapid development of fintech, the system integration needs between large financial institutions and their partners are becoming increasingly complex. The requirements put forward by partners are often vague and multi-layered. For example, the simple description of "needing to accept QR code acquiring transactions through payment channels A and B via a bank" may imply requirements such as settlement time limits, secondary clearing, confirmation and clearing, and regulatory compliance. Meanwhile, large financial institutions currently generally face the following situations and problems:

[0060] 1. Inefficient screening of homogeneous interfaces

[0061] Large financial institutions typically possess a vast number of APIs, many of which overlap or share similar functionalities. For example, an API for payment integration might have multiple versions, supporting different payment channels, performance parameters (such as response time and throughput), or applicable scenarios (such as large-value transactions versus small-value, high-frequency transactions). Faced with vague requirements from partners, it's necessary to analyze the functionality, limitations, and applicability of each API to select a single API or combination of APIs that meets the needs. This selection process often requires extensive comparisons and testing, is inefficient, and is prone to overlooking optimal solutions due to human error.

[0062] 2. The complexity of implementing interface composition

[0063] When a single interface cannot fully meet the requirements, a combination of multiple existing interfaces needs to be designed. For example, to achieve the requirement of "clearing after confirmation," it may be necessary to combine the payment interface, order splitting interface, and query interface. However, the complexity of this combination logic increases significantly, potentially involving the following challenges:

[0064] Interface compatibility: Data formats, call order, or dependencies between different interfaces may not be completely compatible.

[0065] Performance bottleneck: Serial calls to multiple interfaces may lead to increased latency or excessive system load.

[0066] Security risks: Interface composition may introduce new security vulnerabilities, such as data breaches or unauthorized access. These issues significantly increase the development and verification costs of interface composition solutions.

[0067] 3. Insufficient ability to respond quickly to market changes

[0068] In today's rapidly changing financial market environment, partner and regulatory requirements can change frequently. Traditional manual analysis and interface screening methods struggle to adapt quickly to these changes, causing financial institutions to lag behind in responding to demands and impacting customer satisfaction.

[0069] To address the aforementioned issues, this application provides an application programming interface (API) recommendation method and related apparatus. By combining natural language processing technology with knowledge graph reasoning, it achieves automated parsing of financial business requirements and mining of implicit needs. Based on multi-dimensional feature vectorization matching technology, it selects the optimal API or API combination from a massive number of API interfaces, thereby solving the problems of ambiguous requirements, inefficient interface selection, and complex combination logic in financial system integration, effectively improving the user experience.

[0070] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0071] Figure 1 This is a schematic diagram of a scenario provided for an embodiment of this application, such as... Figure 1 As shown, it includes client 1 and server 2.

[0072] Users can input business requirements through the interactive interface in client 1, and client 1 can send the received business requirements to server 2.

[0073] Server 2 can analyze and identify the received business requirements, filter out the API interfaces or API interface combinations that match the business requirements from the API interface library, and send the filtered API interfaces or API interface combinations to client 1.

[0074] Client 1 can output the received API interface or a combination of API interfaces to the user.

[0075] Below Figure 1 Based on the scenario shown, the recommended method for application programming interfaces provided in the embodiments of this application will be described with the server as the execution subject.

[0076] Figure 2 A flowchart illustrating an application programming interface (API) recommendation method provided in this application embodiment is shown below. Figure 2 As shown, it includes:

[0077] S201. Obtain the user's business requirement text, as well as the interface characteristics of each application interface in the application interface library.

[0078] In some embodiments, the user's business request text can be text input by the user based on natural language, used to indicate a business request for financial services. For example, the business request text could be "Support QR code acquiring for payment channels A and B".

[0079] Application Programming Interface (API) interface features can refer to the features used to describe the key attributes, behaviors, and structural characteristics of an API interface.

[0080] In some embodiments, the system may receive user input in natural language and store the requirements as text to obtain a business requirement text.

[0081] It can extract basic information, parameter features, call features, and performance features of each API interface, and then vectorize the basic information, parameter features, call features, and performance features respectively. Finally, it can fuse the resulting vectors to obtain the interface features of each API interface.

[0082] S202. Process the business requirement text to determine the user's explicit requirements for the application interface.

[0083] In some embodiments, explicit requirement features of an application programming interface (API) may refer to requirement features directly expressed in the business requirement text.

[0084] In one possible implementation, a natural language model can be used to process the business requirement text and determine the user's explicit requirements for the application interface.

[0085] For example, the BERT model can be used to perform semantic recognition on business requirement texts, and the corresponding requirements can be selected from predefined standardized requirements based on the semantic recognition results, thereby obtaining the explicit requirement features indicated in the business requirement texts.

[0086] In one possible implementation, a large language model can be used to process the business requirement text and determine the user's explicit requirements for the application interface.

[0087] For example, guide words can be constructed to enable the large language model to understand the business requirement text, thereby obtaining the explicit requirement features indicated in the business requirement text output by the large language model.

[0088] S203. Extract the implicit requirements of users for application interfaces from the explicit requirements, and determine the target requirements based on the explicit and implicit requirements.

[0089] In some embodiments, the implicit requirement features of an application programming interface (API) may refer to the requirement features that may be implied in the business requirement text.

[0090] In one possible implementation, a large language model can be used to process explicit requirement features and business requirement text, so that the speech model can uncover the user's implicit requirement features for the application interface.

[0091] In one possible implementation, explicit demand features can be treated as known entities, and implicit demand features can be obtained by performing relational path reasoning on the explicit demand features using a knowledge graph. The knowledge graph can be a pre-constructed financial business knowledge graph.

[0092] In some embodiments, after obtaining explicit demand characteristics and implicit demand characteristics, the explicit demand characteristics and implicit demand characteristics can be merged to obtain target demand characteristics.

[0093] S204. Match the target requirement characteristics with the application interface characteristics, and output the recommended application interface.

[0094] In some embodiments, after determining the target requirement features and the interface features of the application programming interface (API), the similarity between the target requirement features and the interface features can be calculated, and a recommended API can be output based on the similarity.

[0095] For example, calculate the cosine similarity between target requirement features and interface features, and recommend interfaces with a cosine similarity greater than or equal to a preset threshold as application interfaces.

[0096] The application programming interface (API) recommendation method provided in this application embodiment obtains the user's business requirement text and the interface features of each API in the API library; processes the business requirement text to determine the user's explicit requirement features for APIs; mines the user's implicit requirement features for APIs from the explicit requirement features, and determines the target requirement features based on the explicit and implicit requirement features; matches the target requirement features with the interface features of the APIs, and outputs recommended APIs. This method, by extracting explicit requirements and mining implicit requirements from business requirements, and based on feature matching technology, can filter out the optimal API or API combination from a massive number of APIs, thereby solving the problems of ambiguous requirements, inefficient API selection, and complex combination logic in financial system integration, effectively improving the user experience.

[0097] Below, in Figure 2 Based on the embodiments shown, the application programming interface recommendation method provided in this application embodiment will be further explained.

[0098] Figure 3 A flowchart illustrating an application programming interface (API) recommendation method provided in this application embodiment. Figure 2 ,like Figure 3 As shown, it includes:

[0099] S301. Obtain the user's business requirement text, as well as the interface parameters of each application interface in the application interface library.

[0100] The specific implementation method of step S301 in the embodiments of this application is the same as Figure 2 The specific implementation methods in the illustrated embodiments are similar.

[0101] S302. Preprocess the business requirement text to obtain structured business requirements.

[0102] In some embodiments, preprocessing of business requirement text may include cleaning, word segmentation, and part-of-speech tagging of the business text.

[0103] For example, cleaning business requirement text can include removing all punctuation marks, extra spaces, and special characters from the text, and unifying synonyms / near-synonyms.

[0104] In some embodiments, the cleaned and normalized text can be segmented and tagged with parts of speech to obtain a structured segmented sequence with part-of-speech tags, i.e., structured business requirements.

[0105] For example, a pre-trained natural language model (such as the BERT model) can be used to perform context-aware word segmentation on normalized text, while also tagging each word segment with part-of-speech tags.

[0106] For example, the standardized text is: "Supports bank settlement, WeChat and Alipay QR code payment."

[0107] The result of BERT word segmentation is: "Support / bank settlement / 、 / WeChat / and / Alipay / QR code / acceptance".

[0108] For example, input text example: "Banks integrate WeChat and Alipay QR code payment collection".

[0109] Part-of-speech tagging results: "bank" (n. institution), "access" (v. action), "WeChat" (n. payment platform), "Alipay" (n. payment platform), "QR code payment" (n. business operation).

[0110] S303. Based on the structured business requirements and the standardized requirements corresponding to the requirements documents, determine the characteristics of explicit requirements.

[0111] In some embodiments, the requirement documents are documents in a pre-maintained, structured library of financial business requirements, with each document describing a standard business requirement. Examples include: "bank card payment," "QR code payment," and "asynchronous notification of transaction results."

[0112] For example, key requirements can be located from structured business requirements based on part-of-speech tagging; at least one requirement document can be selected from the requirement document library based on the key requirements; and explicit requirement features can be determined based on the standardized requirements corresponding to the requirement document.

[0113] Among them, key requirements can refer to the requirements corresponding to keywords or core terms in structured business requirements.

[0114] For example, dependency parsing can be used, combined with tagged parts of speech, to locate keywords from business requirements. For instance, from the word segmentation results of "supports bank settlement, WeChat and Alipay QR code payment," "QR code payment" can be selected as the core keyword.

[0115] After identifying the keywords, a relevance algorithm (such as the BM25 algorithm) can be used to calculate the relevance between the key requirements and each requirement document, and retrieve the set of documents that best match the requirements.

[0116] For example, the BM25 algorithm can be shown as follows:

[0117]

[0118] The preprocessed requirement text as input;

[0119] Keywords are located in the requirements document;

[0120] Keywords Frequency of appearance in the document;

[0121] Inverse document frequency of keywords;

[0122] and BM25 adjustment parameters, typically set to [value]. = 1.2 and = 0.75. If you want to rely more on keyword frequency, improve... If you don't want to over-penalize long documents, you can reduce the penalty. .

[0123] After retrieving the Top-K most relevant requirement documents, the standardized requirement points they represent are designated as explicit requirements.

[0124] For example, explicit requirements include ["clearing channel", "QR code payment", "WeChat Pay", "Alipay payment"].

[0125] S304. Use the knowledge graph to perform relational path reasoning on explicit demand features to obtain implicit demand features.

[0126] For example, a low-dimensional vector mapping is performed on a preset business knowledge graph to obtain a target knowledge graph; wherein, nodes in the business knowledge graph identify business entities, and edges represent the relationships between business entities; explicit requirement features are taken as known entities, and relational path reasoning is performed on explicit requirement features in the target knowledge graph to obtain implicit requirement features.

[0127] For example, using graph embedding models such as TransE, entities and relationships in the business knowledge graph are mapped to a low-dimensional vector space to obtain the target knowledge graph. Explicit requirement features are treated as known entities, and relational path reasoning is performed on these explicit requirement features in the target knowledge graph to discover related implicit requirements that are not directly mentioned in the text.

[0128] For example, starting from the explicit need "scan to pay", through relational reasoning, implicit needs ["payment routing", "risk single transaction monitoring", "daily transaction limit verification"] may be obtained.

[0129] S305. Combine explicit and implicit demand characteristics to obtain target demand characteristics.

[0130] For example, explicit and implicit demand features are merged to obtain a demand set; each demand in the demand set is converted into a corresponding sub-vector; and the sub-vectors are fused based on a preset fusion strategy to obtain the target demand feature.

[0131] For example, the explicit and implicit requirement lists can be merged to form a complete, deduplicated set of requirement points. Embedding techniques (such as Sentence-BERT) are then used to transform each requirement point into a sub-vector. Through pooling operations (such as average pooling) or attention mechanisms, all sub-vectors are fused into a fixed-dimensional multi-dimensional requirement feature vector, thus obtaining the target requirement feature.

[0132] For example, the feature vector form of the target requirement feature is as follows:

[0133]

[0134] in, Indicates the first Each requirement dimension and its corresponding value.

[0135] For example, the demand dimension can include payment method, clearing method, and payment deadline, and the corresponding feature vector could be:

[0136] =[Payment method: WeChat / Alipay, Settlement method: Two-tier, Settlement time limit: T+1]

[0137] S306. Vectorize the interface parameters of the application interface and fuse the resulting vectors to obtain interface features.

[0138] In some embodiments, the interface parameters of the application programming interface may include basic information, parameter characteristics, invocation characteristics, and performance characteristics.

[0139] Basic information, parameter features, call features, and performance features can be vectorized separately to obtain basic information vectors, parameter vectors, call vectors, and performance feature vectors of the application programming interface (API). The basic information vectors, parameter vectors, call vectors, and performance feature vectors can then be fused to obtain the features of the API.

[0140] The basic information vector can be obtained by fusing the semantic vector and path vector corresponding to the basic information.

[0141] For example, basic information is encoded to obtain semantic vectors corresponding to the basic information; the path hierarchy of the application interface is vectorized, and the vectors corresponding to each path hierarchy are fused to obtain the path vector of the application interface; the semantic vector and the path vector are fused to obtain the basic information vector.

[0142] The processes for obtaining the basic information vector, parameter vector, call vector, and performance feature vector are explained below:

[0143] 1. Basic information vector.

[0144] The basic information of the API interface (name, description, tags, path, etc.) is parsed. First, BERT is used to encode the text fields to generate semantic vectors.

[0145]

[0146] Then, Word2Vec is used to vectorize the path hierarchy, generating API path vectors that include semantic features.

[0147] Taking / api / v1 / payment / qrcode as an example:

[0148] Path segment Word2Vec vector API [0.1, 0.5, -0.3] v1 [0.2, 0.1, 0.4] Payment [0.7, 0.8, 0.6] QR code [0.9, 0.3, 0.2]

[0149] Different weights are assigned based on the hierarchical position of the path segment (the deeper the segment, the smaller the weight), for example:

[0150]

[0151] Assume the weights decrease in hierarchy:

[0152] First layer (api): =0.4

[0153] Second layer (v1): w=0.3

[0154] Third layer (payment): w=0.2

[0155] Fourth layer (qrcode): w=0.1

[0156] Therefore, the vector for the path / api / v1 / payment / qrcode is:

[0157]

[0158] The semantic vector and path vector are fused to obtain the basic information vector. .

[0159]

[0160] 2. Parameter vector.

[0161] The API request and return parameters are analyzed in detail, and the multidimensional features of the parameters are extracted and quantized.

[0162] For example, request and response parameters include:

[0163] Parameter names (e.g., user_id, amount);

[0164] Parameter type (int, float, string, boolean, object, array);

[0165] Required / optional;

[0166] Nesting levels (supports multi-level nested JSON parsing);

[0167] Each parameter feature vector is concatenated to form a complete parameter vector. .

[0168]

[0169] 3. Call the vector.

[0170] The API's calling method, authentication, timeout, version, and other characteristics are parsed and vectorized.

[0171] For example, for each API interface, extract the following call characteristics:

[0172] Request methods (GET / POST / PUT / DELETE);

[0173] Authentication methods (OAuth, API Key, Basic Auth, no authentication);

[0174] Timeout duration (in milliseconds);

[0175] API version (e.g., v1, v2.0);

[0176] Specifically, the request method uses One-Hot encoding, the authentication method uses tag encoding, the timeout is normalized to the range [0,1], and the API version is embedded in ordinal order.

[0177] Each call feature vector is concatenated to form a complete call vector. .

[0178]

[0179] 4. Performance feature vector.

[0180] Vectorize the runtime performance data of the API.

[0181] For example, performance data includes the following:

[0182] Call duration (unit: ms, average value).

[0183] Success rate (the average success rate over a recent period).

[0184] QPS (Queries Per Second, representing the API's load capacity).

[0185] Each performance data vector is concatenated to form a complete performance feature vector. .

[0186] =

[0187] The four types of feature vectors are then weighted and fused to generate a unified API vector representation:

[0188]

[0189] in, It has adjustable weights, which can be adjusted according to actual needs.

[0190] S307. Match the target requirement characteristics with the interface characteristics of the application interface, and output the recommended application interface.

[0191] For example, the similarity between the target requirement features and each interface feature is obtained; if there is an interface feature whose similarity meets a preset threshold, the application interface corresponding to that interface feature is used as the recommended application interface; if there is no interface feature whose similarity meets the preset threshold, the corresponding application interface combination is selected from multiple application interfaces, and the application interface combination is used as the recommended application interface.

[0192] For example, cosine similarity can be used to calculate the similarity between the target requirement features and the features of each interface.

[0193]

[0194] When the cosine similarity equals a preset threshold (e.g., 1), it can be determined that a single API can fully meet the requirements. When the matching degree is less than the preset threshold, it indicates that some key requirements are not fully covered, and it is necessary to consider introducing new APIs to fill the gaps in requirements.

[0195] In some embodiments, filtering a combination of application programming interfaces (APIs) from a plurality of APIs can be performed in the following manner:

[0196] For example, the target requirement features are broken down into multiple sub-requirements; for each sub-requirement, the similarity between the sub-requirement and the interface features is obtained, and candidate interface combinations corresponding to the sub-requirement are obtained based on the similarity; based on the calling dependencies of the application interfaces, the target interface combination is determined from the candidate interface combinations; based on the preset combination evaluation rules, the recommended application interface combination is selected from the target interface combination.

[0197] For example, the complete target requirement features (requirement feature vector) can be reverse mapped or decomposed into its corresponding set of sub-requirement points. For each sub-requirement point, the cosine similarity between its vector and all API vectors is calculated separately, and the API (or candidate API set) with the highest matching degree is found for each sub-requirement.

[0198] Consider business logic and analyze the call dependencies between different APIs. For example, the "Payment API" must be called before the "Result Query API" can be called. Based on the sub-requirement matching results and API dependencies, generate candidate API call paths or combinations of API call paths.

[0199] Use the path coverage formula to evaluate the functional coverage completeness (whether the combination can cover all sub-requirements) and logical correctness (whether the order of API calls within the combination conforms to business dependencies).

[0200] The path coverage formula is as follows:

[0201]

[0202] in, Indicates the API call path, It is the similarity between each sub-requirement fragment and the API in the path; It is an indicator function that calls the path to satisfy the condition of the dependency relationship. It is 1 if the dependency is satisfied, and 0 otherwise. It represents the total demand, ensuring that the value is normalized to [0,1].

[0203] In financial business scenarios, every operation must strictly comply with business, compliance, and risk control requirements, requiring stringent threshold judgments. Therefore, whether a recommended API combination can meet business needs can be checked and determined using the strategy shown below.

[0204] 1. For each sub-requirement in the combination, its matching degree with the assigned API must reach or exceed the threshold 1.

[0205] 2. Discretize the matching results of each sub-requirement in binary form: if the matching degree is greater than or equal to the threshold 1, it is recorded as 1 (match), otherwise it is recorded as 0 (no match).

[0206] Based on this, the formula for calculating the overall path coverage can be expressed as:

[0207]

[0208] The candidate API interface combinations are evaluated based on the above method. If a qualified API interface combination is found, it is output as the recommended solution. If no API interface combination can pass the judgment, "No API interface combination that fully meets the requirements can be found" is output, and the key sub-requirements that are not fully covered are listed for business personnel to review or adjust the requirements.

[0209] The application programming interface (API) recommendation method provided in this application uses natural language and knowledge graph reasoning to extract both explicit and implicit requirements, ensuring comprehensive requirement coverage. Through multi-dimensional feature vectorization and similarity calculation, it accurately matches interfaces, avoiding the mismatch problems of traditional rule engines. By analyzing the completeness and dependencies of interface combinations using path coverage formulas, it ensures that the combination schemes comply with business logic and compliance requirements, reducing manual design costs. The system quickly adapts to market changes by updating the requirement set library and API feature vectors, eliminating the need for manual rule or script updates and significantly shortening requirement response time. In summary, this application solves the problems of ambiguous requirements, inefficient interface selection, and complex combination logic in financial system integration, providing financial institutions with an efficient and flexible automated solution.

[0210] Based on the above embodiments, this application also provides an application programming interface (API) recommendation device.

[0211] Figure 4 A schematic diagram of the structure of the application programming interface recommendation device 40 provided in the embodiments of this application is shown below. Figure 4 As shown, it includes:

[0212] The acquisition module 401 is used to acquire the user's business requirement text, as well as the interface characteristics of each application interface in the application interface library.

[0213] The first processing module 402 is used to process the business requirement text and determine the user's explicit requirements for the application interface.

[0214] The second processing module 403 is used to extract the implicit requirements of users for application interfaces from explicit requirements features, and to determine the target requirements features based on explicit and implicit requirements features.

[0215] Matching module 404 is used to match the target requirement characteristics with the interface characteristics of the application interface and output a recommended application interface.

[0216] In some embodiments, the first processing module 402 is used to clean, segment, and tag the business requirement text to obtain structured business requirements; based on the part-of-speech tags in the structured business requirements, locate key requirements from the structured business requirements; based on the key requirements, select at least one requirement document from the requirement document library, and determine explicit requirement features based on the standardized requirements corresponding to the requirement document.

[0217] In some embodiments, the second processing module 403 is used to perform low-dimensional vector mapping on a preset business knowledge graph to obtain a target knowledge graph; wherein, nodes in the business knowledge graph identify business entities, and edges represent the relationships between business entities; explicit demand features are taken as known entities, and relational path reasoning is performed on the explicit demand features in the target knowledge graph to obtain implicit demand features.

[0218] In some embodiments, the second processing module 403 is used to merge explicit demand features and implicit demand features to obtain a demand set; convert each demand in the demand set into a corresponding sub-vector; and fuse the sub-vectors based on a preset fusion strategy to obtain the target demand feature.

[0219] In some embodiments, the acquisition module 401 is used to acquire interface parameters of the application interface; the interface parameters include basic information, parameter features, call features and performance features; the basic information, parameter features, call features and performance features are vectorized respectively to obtain the basic information vector, parameter vector, call vector and performance feature vector of the application interface; the basic information vector, parameter vector, call vector and performance feature vector are fused to obtain the features of the application interface.

[0220] In some embodiments, the acquisition module 401 is used to encode the basic information to obtain the semantic vector corresponding to the basic information; to vectorize the path hierarchy of the application interface and to fuse the vectors corresponding to each path hierarchy to obtain the path vector of the application interface; and to fuse the semantic vector and the path vector to obtain the basic information vector.

[0221] In some embodiments, the matching module 404 is used to obtain the similarity between the target requirement feature and each interface feature; if there is an interface feature whose similarity meets a preset threshold, the application interface corresponding to the interface feature is used as the recommended application interface; if there is no interface feature whose similarity meets the preset threshold, the corresponding application interface combination is selected from multiple application interfaces, and the application interface combination is used as the recommended application interface.

[0222] In some embodiments, the matching module 404 is used to decompose the target requirement features into multiple sub-requirements; for each sub-requirement, obtain the similarity between the sub-requirement and the interface features, and obtain the candidate interface combination corresponding to the sub-requirement based on the similarity; determine the target interface combination from the candidate interface combinations based on the application interface call dependency relationship; and select the recommended application interface combination from the target interface combination based on the preset combination evaluation rules.

[0223] The application programming interface (API) recommendation device provided in this application embodiment can execute the API recommendation method shown in any of the above embodiments. Its principle and technical effect are similar, and will not be described again here.

[0224] This application also provides an electronic device.

[0225] Figure 5 This is a schematic diagram of the structure of the electronic device 50 provided in the embodiments of this application, such as... Figure 5 As shown, the electronic device may include: a transceiver 501, a processor 502, and a memory 503.

[0226] Processor 502 executes computer execution instructions stored in memory, causing processor 502 to perform the scheme in the above embodiments. Processor 502 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0227] The memory 503 is connected to the processor 502 via the system bus and completes communication between them. The memory 503 is used to store computer program instructions.

[0228] Transceiver 501 can perform the functions of receiving and sending data and instructions.

[0229] Optionally, the electronic device 50 may also include a communication interface 504, which allows communication and interaction with external or internal devices via the communication interface 503. External devices may be, for example, client devices (e.g., mobile phones, tablets). In specific implementations, if the communication interface 504, memory 503, and processor 502 are implemented independently, they can be interconnected via a bus to complete communication with each other.

[0230] The system bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The system bus can be divided into address bus, data bus, control bus, etc. For ease of representation, only one thick line is used in the diagram, but this does not indicate that there is only one bus or one type of bus. Transceivers are used to enable communication between database access devices and other computers (e.g., clients, read-write libraries, and read-only libraries). Memory may include random access memory (RAM) and may also include non-volatile memory.

[0231] Optionally, in a specific implementation, if the communication interface 504, memory 503, and processor 502 are integrated on a single chip, then the communication interface 504, memory 503, and processor 502 can communicate through an internal interface.

[0232] This application also provides a chip for executing instructions, which is used to execute the technical solutions of the methods described in the above embodiments.

[0233] This application also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the technical solution of the above method embodiment. Its implementation principle and technical effect are similar, and will not be repeated here.

[0234] In one possible implementation, a computer-readable medium may include random access memory (RAM), read-only memory (ROM), compact discread-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0235] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the technical solution of the above method embodiments. Its implementation principle and technical effects are similar, and will not be repeated here.

[0236] In the specific implementation of the aforementioned terminal device or server, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.

[0237] Those skilled in the art will understand that all or part of the steps in any of the above method embodiments can be implemented by hardware associated with program instructions. The aforementioned program can be stored in a computer-readable storage medium, and when the program is executed, all or part of the steps in the above method embodiments are performed.

[0238] If the technical solution of this application is implemented in software form and sold or used as a product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the technical solution of this application can be embodied in the form of a software product, which is stored in a storage medium and includes a computer program or several instructions. This computer software product enables a computer device (which may be a personal computer, server, network device, or similar electronic device) to execute all or part of the steps of the methods in the embodiments of this application.

[0239] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0240] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0241] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0242] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0243] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0244] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). 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 memory 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 of the various embodiments of this application. The aforementioned memory 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.

[0245] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0246] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. An application program interface recommendation method characterized by, The application comprises the following steps: obtaining the business requirement text of a user, and obtaining the interface characteristics of each application interface in an application interface library; processing the business requirement text to determine the explicit requirement characteristics of the user for the application interface; mining the implicit requirement characteristics of the user for the application interface from the explicit requirement characteristics, and determining the target requirement characteristics based on the explicit requirement characteristics and the implicit requirement characteristics; matching the target requirement characteristics with the interface characteristics of the application interface, and outputting the recommended application interface.

2. The method of claim 1, wherein, The processing of the business requirement text to determine the explicit requirement characteristics of the user for the application interface comprises the following steps: cleaning, tokenizing and part-of-speech tagging the business requirement text to obtain a structured business requirement; locating key requirements from the structured business requirement based on the part-of-speech tagging in the structured business requirement; screening at least one requirement document from a requirement document library based on the key requirements, and determining the explicit requirement characteristics based on the standardized requirements corresponding to the requirement document.

3. The method of claim 2, wherein, The mining of the implicit requirement characteristics of the user for the application interface from the explicit requirement characteristics comprises the following steps: performing low-dimensional vector mapping on a preset business knowledge graph to obtain a target knowledge graph; wherein the nodes in the business knowledge graph represent business entities, and the edges represent the relationships between the business entities; performing relationship path reasoning on the explicit requirement characteristics in the target knowledge graph by taking the explicit requirement characteristics as known entities to obtain the implicit requirement characteristics.

4. The method of claim 3, wherein, The determination of the target requirement characteristics based on the explicit requirement characteristics and the implicit requirement characteristics comprises the following steps: merging the explicit requirement characteristics and the implicit requirement characteristics to obtain a requirement set; converting each requirement in the requirement set into a corresponding sub-vector; fusing the sub-vectors based on a preset fusion strategy to obtain the target requirement characteristics.

5. The method according to claim 1 or 4, characterized in that, The obtaining of the interface characteristics of each application interface in the application interface library comprises the following steps: obtaining the interface parameters of the application interface; the interface parameters comprise basic information, parameter characteristics, calling characteristics and performance characteristics; respectively performing vectorization processing on the basic information, the parameter characteristics, the calling characteristics and the performance characteristics to obtain the basic information vector, the parameter vector, the calling vector and the performance characteristic vector of the application interface; fusing the basic information vector, the parameter vector, the calling vector and the performance characteristic vector to obtain the characteristics of the application interface.

6. The method of claim 5, wherein, The vectorization processing of the basic information to obtain the basic information vector of the application interface comprises the following steps: encoding the basic information to obtain the semantic vector corresponding to the basic information; vectorizing the path levels of the application interface, and fusing the vectors corresponding to the path levels to obtain the path vector of the application interface; fusing the semantic vector and the path vector to obtain the basic information vector.

7. The method of claim 6, wherein, The matching the target demand feature with the interface features of the application program interfaces outputs a recommended application program interface, including: obtaining the similarity of the target demand feature and each interface feature; if there is an interface feature with a similarity meeting a preset threshold, the application program interface corresponding to the interface feature is taken as the recommended application program interface; if there is no interface feature with a similarity meeting a preset threshold, a corresponding application program interface combination is selected from the plurality of application program interfaces, and the application program interface combination is taken as the recommended application program interface.

8. The method of claim 7, wherein, The selecting a corresponding application program interface combination from the plurality of application program interfaces includes: decomposing the target demand feature into a plurality of sub-demands; for each sub-demand, obtaining the similarity of the sub-demand and the interface features, and obtaining a candidate interface combination corresponding to the sub-demand based on the similarity; determining a target interface combination from the candidate interface combinations based on the calling dependency relationship of the application program interfaces; selecting a recommended application program interface combination from the target interface combination based on a preset combination evaluation rule.

9. An application program interface recommendation apparatus characterized by comprising: It includes: an acquisition module configured to acquire a business demand text of a user and interface features of each application program interface in an application program interface library; a processing module configured to process the business demand text based on a natural language model to determine explicit demand features of the user for the application program interfaces; a determination module configured to mine implicit demand features of the user for the application program interfaces from the explicit demand features, and determine a target demand feature based on the explicit demand features and the implicit demand features; a recommendation module configured to match the target demand feature with the interface features of the application program interfaces to output a recommended application program interface.

10. An electronic device, comprising: It includes: a memory configured to store a computer program; a processor configured to execute the computer program to implement the method of any one of claims 1-8.

11. A computer readable storage medium, characterized in that, A computer program is stored thereon, and the computer program is executed by a processor to implement the method of any one of claims 1-8.

12. A computer program product, characterised in that, It includes a computer program, which is executed by a controller to implement the method of any one of claims 1-8.

Images