A Request Parameter Conversion Method for Web API Calls

Abstract

The present invention designs a request parameter conversion method for Web API calls, which involves the fields of Web API intelligent matching and Web API recommendation. By dividing request parameters into seven types and utilizing the dependencies between request parameters, a new Web API that meets development needs can be recommended to developers more accurately based on the request data and specified return data provided by the developer. The method can also help developers solve the request parameter conversion problem when automatically replacing an invalid Web API with a new one, thereby achieving the goal that when a Web API becomes invalid, a new Web API can be used to automatically replace the invalid Web API without reading the development documentation of the new Web API and providing specified request parameters, thereby simplifying the software development process while ensuring the same system effect.

Description

Technical Field

[0001] The present invention relates to the fields of Web API intelligent matching and Web API recommendation, and particularly to a method for converting request parameters for Web API calls. Background Art

[0002] With the rapid development of Web technology, Web services have made great progress in the Web 2.0 era. It goes beyond the existing closed Web services and can freely open and share information. Instead of developing new systems from scratch, developers combine existing Web service application programming interfaces (i.e., Web APIs) for software development, which has become an efficient method. Developers need to find suitable Web APIs according to actual development needs, and when calling Web APIs, they need to read the instruction documents provided by manufacturers and provide specified request parameters to successfully call Web APIs in the way specified in the development documents.

[0003] However, against the backdrop of the continuous growth of Web APIs, once the currently used Web API fails, how to find a new Web API to replace the failed one according to development needs, and how to convert the request parameters of the failed Web API into the request parameters of the new Web API, these two problems bring no small trouble to software development work.

[0004] To help developers more quickly locate suitable Web APIs to replace failed Web APIs, various recommendation methods and models have been applied to the field of Web API recommendation. These recommendation methods are generally divided into two categories, collaborative filtering-based recommendation methods and content-based recommendation methods. Collaborative filtering-based recommendation algorithms make predictions through historical relationships, recommend Web APIs by calculating similarities and using similar information. Content-based recommendation first performs topic modeling on development requirements, and then recommends Web APIs using the correlation between development requirements and Web APIs. The functions of the above two categories of recommendation methods are essentially to recommend Web APIs with the same or similar functions to developers.

[0005] The instruction documents provided by major manufacturers specify the request parameter information that must be passed when calling a Web API, as well as the return parameter information obtained after calling this Web API. The request data provided by developers must exactly match the request parameters required by the document in order to successfully call a Web API and obtain the correct response result.

[0006] First, although the current recommendation method selects a Web API with the same or similar functionality as the deprecated Web API, the request parameters of the recommended new Web API are different from those of the deprecated Web API, from the number of parameters to the parameter types. Therefore, developers cannot simply replace the deprecated Web API with the new one. Instead, they must read the development documentation of the new Web API, provide the specified request parameters as required, and call the new Web API again. This process of re-preparing request parameters according to the Web API documentation still consumes a lot of developer effort.

[0007] Secondly, the current recommendation method is to select Web APIs with the same or similar functions as the invalid Web API based on the granularity of Web API functions. When developers use Web APIs, they use the return parameter values obtained after calling the Web API. Therefore, if the return parameters of the selected new Web API are not necessarily the same as the return parameters of the invalid Web API (if the core return parameter values are missing), the new Web API will not be usable. In other words, although the new Web API recommended by the current recommendation method is functionally consistent with the invalid Web API, there is no guarantee that the new Web API can replace the invalid Web API.

[0008] In addition, current recommendation methods are too cumbersome, requiring either consideration of historical relationships or topic modeling. The amount of data and information that needs to be analyzed during the recommendation process is too large, the process is complex, and the effect is mediocre.

[0009] In summary, the existing recommendation methods cannot help developers recommend WebAPIs that fully meet their needs, and cannot solve the problems encountered in automatic replacement and request parameter conversion during the Web API replacement process. Summary of the invention

[0010] Aiming at the deficiencies of the prior art, the present invention provides a request parameter conversion method for Web API calls. By classifying request parameters into seven types and utilizing the dependency relationships between request parameters, only based on the request data provided by developers and the specified return data, it is possible to more accurately recommend new Web APIs that meet the development requirements to developers, and can help developers solve the problem of request parameter conversion when automatically replacing invalid Web APIs with new Web APIs. Furthermore, when a Web API becomes invalid, without the need to read the development documentation of the new Web API and provide the specified request parameters, a new Web API can be automatically used to replace the invalid Web API, simplifying the software development process while ensuring the same system effect.

[0011] A request parameter conversion method for Web API calls specifically includes the following steps:

[0012] Step 1: Construct a Web API experimental data set; the Web API experimental data set contains multiple structured Web API experimental data, and the Web API experimental data includes a request parameter set, a return parameter set, and basic information; among them, the request parameter set contains several request parameters, and a request parameter contains several fields, specifically including: parameter name field, parameter type field, parameter meaning field, required field, and example field; the return parameter set contains several return parameters, and a return parameter contains several fields, specifically including: parameter name field, parameter type field, parameter meaning field, and example field; the basic information includes: function description, call address, call method, and call example of the Web API;

[0013] Step 1.1: Crawl and screen Web API description documents;

[0014] First, crawl a large number of Web API description documents from the developer platforms provided by major SaaS manufacturers, and then screen out high-quality and complete Web API description documents through keyword matching methods;

[0015] The screening through keyword matching is specifically as follows: preset the keywords to be matched, including: interface basic information, request address, request parameters, request examples, return parameters, response examples. If a Web API description document contains all the keywords, retain this description document; if a Web API description document does not completely contain all the keywords, eliminate this description document;

[0016] Step 1.2: Construct a data set;

[0017] From the description documents of the selected Web APIs, store the data of each Web API description document in the database in the form of structured data; at the same time, according to the parameter descriptions in the development documents, store the dependency relationships between request parameters and between request parameters and return parameters in the database as well;

[0018] Step 2: Classify the Web API experimental dataset constructed above;

[0019] Specifically: According to the function descriptions of each Web API in the dataset, classify them through the Naive Bayes algorithm;

[0020] Step 3: Standardize each native request parameter and native return parameter of each Web API in the Web API experimental dataset;

[0021] Utilize the Word2Vec model to convert the processing of text content into vector operations in space by converting words into vector forms, and then calculate the similarity in the vector space to represent the semantic similarity of the text;

[0022] Step 3.1: Initialization;

[0023] Before initialization, apiStdReq is empty. At this time, directly add the request parameter set of the first Web API to apiStdReq as the initial data of apiStdReq, and directly add the return parameter set of the first Web API to apiStdRes as the initial data of apiStdReq;

[0024] Step 3.2: Standardization;

[0025] Next, send the field description information of a request parameter apiReq of the next Web API in the dataset i into the Word2Vec model to obtain a set of word vectors of this field description information, and then use this set of word vectors as the feature vector of this apiReq i ;

[0026] Calculate the cosine similarity between the feature vector of apiReq i and each feature vector of the standardized request parameter set apiStdReq in apiStdReq j to obtain a set of cosine similarity values, and use the largest cosine similarity value as the semantic similarity value sim_score i between apiReq j and apiStdReq max ;

[0027] When sim_score max >= 0.9, then establish the mapping relationship between this apiReq i and this apiStdReq j ; When sim_score max < 0.9, then use apiReq i as a new standardized request parameter and add it to apiStdReq; Finally, construct a standardized request parameter set apiStdReq for the entire Web API experimental dataset;

[0028] Similarly, perform the above processing on the return parameters of all Web APIs in the dataset to obtain a standardized return parameter set apiStdRes.

[0029] Step 3.3: Repeat Step 3.2 until all Web APIs in the experimental dataset are processed;

[0030] Step 4: Classify the types of each request parameter apiReq i of the Web APIs in the experimental dataset;

[0031] Divide all Web API request parameters into two major categories and seven sub - types; The first major category is divided into four types: "required or not", "determine whether the call is successful", "affect some return parameters", and "depend on some request parameters"; The second major category is divided into three types: "must be provided by developers", "can be filled with default values", and "can be filled with false values"; A request parameter can belong to multiple types at the same time;

[0032] Step 4.1: Determine whether apiReq i belongs to the types of "required or not" and "can be filled with default values";

[0033] Specifically: Read the required or not field and example field of apiReq i from the database; If the value of the required or not field is

[0034] "Y", then apiReq i is of the type "required or not"; If the example field has a value (i.e., is not empty), then apiReq i belongs to the type "can be filled with default values";

[0035] Step 4.2: Determine whether apiReq i belongs to the types of "determine whether the call is successful" and "must be provided by developers";

[0036] After analyzing the documentation and making actual calls to multiple Web APIs, several request parameters that play a decisive role in the calls to Web APIs were summarized. They form the set determinedReq, and several request parameters that must be provided by developers were identified. They form the set depReq;

[0037] If apiReq i belongs to determinedReq, then it belongs to the type "determines whether the call is successful"; if apiReq i belongs to depReq, then it belongs to the type "must be provided by the developer";

[0038] Step 4.3: Determine whether apiReq i belongs to the types "affects some return parameters" and "depends on some request parameters";

[0039] Read the dependency relationship of apiReq i from the database and determine whether it belongs to the types "affects some return parameters" and "depends on some request parameters";

[0040] Step 4.4: If apiReq i does not belong to any of the types in Steps 4.1, 4.2, and 4.3, automatically classify it into the type "can be filled with false values";

[0041] Step 5: Convert the request data provided by the user to obtain the complete request parameters and their values that can be used to successfully call the candidate Web APIs;

[0042] Step 5.1: Standardize the request data provided by the user and the specified return data;

[0043] Use the Word2Vec model to calculate the semantic similarity between the request data userReq provided by the developer and the specified return data userRes, and the standardized request parameter set stdReq and the standardized return parameter set stdRes respectively, to obtain the standardized request parameter userStdReq corresponding to the request data provided by the developer, and the standardized return parameter userStdRes corresponding to the specified return data;

[0044] Step 5.2: Obtain the Web API candidate set API_Candidates;

[0045] Based on the userStdRes obtained in the previous step, compare it with the standardized return parameter apiStdRes corresponding to each Web API. If apiStdRes completely contains userStdRes, add the Web API corresponding to this apiStdRes to the Web API candidate set;

[0046] Step 5.3: Construct the CQ for each candidate Web API;

[0047] For each request parameter of each candidate Web API, if it belongs to one of the three types of "whether it is required", "determines whether the call is successful", and "affects some return parameters", directly add it to the CQ; if it belongs to the type of "depends on some request parameters", add the request parameters it depends on to the CQ;

[0048] Step 5.4: Fill in the CQ values;

[0049] For each request parameter cq in the CQ, first determine whether the developer has provided this cq. If not, add this cq to the set of missing request parameters CQ_missing; for each cqm in CQ_missing, if its type is "must be provided by the developer", then data must be requested from the developer again; if its type is "can be filled with the default value", then obtain the value of this cqm from the maintained request parameter default value table for filling; if its type is "can be filled with the false value"; then obtain the value of this cqm from the maintained request parameter false value table for filling;

[0050] The request parameter conversion is completed, and the CQ and its values of each candidate Web API are obtained.

[0051] The beneficial effects produced by adopting the above technical solution are as follows:

[0052] Compared with the prior art, the technical solution proposed by the present invention innovates the traditional Web API recommendation method. Starting from the fine-grained parameter fields, this method makes the Web API recommendation effect more accurate, greatly simplifies the recommendation process, and through calculating the semantic similarity of parameter fields for request parameter conversion, enables the automatic replacement of Web APIs. This method not only considers whether the function of the Web API fits the current development requirements, but also considers whether the return parameters obtained after the Web API call meet the needs of the current system. Description of the Drawings

[0053] Figure 1 It is a flowchart of a request parameter conversion method for Web API calls according to the present invention;

[0054] Figure 2 Screenshot of some request parameters of a Web API in an embodiment of the present invention. Specific implementation manners

[0055] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0056] When the present invention recommends a Web API that matches the development requirements, it not only considers the function of the Web API, but also considers the request parameters and return parameters of the Web API, and recommends the Web API from the granularity of parameter fields, so that the recommended Web API better meets the needs of developers.

[0057] The present invention divides the request parameters into seven types, each type has a corresponding value filling method, and considers the dependency relationships between the request parameters and the return parameters, and between the request parameters and the request parameters, so that the request parameters between two Web APIs can be automatically converted. Thus, when a Web API fails, the selected new Web API can automatically replace the failed Web API, without the need for developers to spend extra time and effort reading the instruction documents and preparing the request parameters.

[0058] The self-constructed dataset used in this solution is used as experimental data. A method for converting request parameters for Web API calls, as shown in the appendix Figure 1 includes the following steps:

[0059] Step 1: Construct a Web API experimental dataset; the Web API experimental dataset contains multiple pieces of structured Web API experimental data, and the Web API experimental data contains a request parameter set, a return parameter set, and basic information; among them, the request parameter set contains several request parameters, and a request parameter contains several fields, specifically including: parameter name field, parameter type field, parameter meaning field, required field, and example field; the return parameter set contains several return parameters, and a return parameter contains several fields, specifically including: parameter name field, parameter type field, parameter meaning field, and example field; the basic information includes: function description, call address, call method, and call example of the Web API;

[0060] Step 1.1: Crawl and screen Web API instruction documents;

[0061] First, crawl a large number of Web API instruction documents from the developer platforms provided by major SaaS manufacturers, and then screen out high-quality and complete Web API instruction documents through keyword matching methods;

[0062] The screening by keyword matching is specifically as follows: Preset the keywords to be matched, including: basic interface information, request address, request parameters, request examples, return parameters, response examples. If a Web API description document contains all the keywords, keep this description document; if a Web API description document does not completely contain all the keywords, eliminate this description document;

[0063] Step 1.2: Construct a data set;

[0064] From the description documents of the screened Web APIs, store the data of each Web API description document in the database in a structured data form; at the same time, according to the parameter descriptions in the development documents, store the dependency relationships between request parameters and the dependency relationships between request parameters and return parameters in the database;

[0065] Step 2: Classify the Web API experimental data set constructed above;

[0066] Specifically: According to the function descriptions of each Web API in the data set, classify it through the Naive Bayes algorithm;

[0067] Appendix Figure 2 Partial request parameter screenshots of a certain Web API;

[0068] The Web API categories in the experimental data set and the number of each category. The Web API categories here are not the classifications in Step 2, but only the major categories when collecting data. For example, in the logistics Web API, it includes: Create an order API, Get order logistics information API, Order cancellation API, Logistics track push API, etc. APIs.

[0069] The classification in Step 2 is to classify all Web APIs into finer categories.

[0070]

[0071] Step 3: Standardize each native request parameter and native return parameter of each Web API in the Web API experimental data set;

[0072] Use the Word2Vec model to convert the processing of text content into vector operations in space by converting words into vector forms, and then calculate the similarity in the vector space to represent the semantic similarity of the text;

[0073] Step 3.1: Initialization;

[0074] Before initialization, apiStdReq is empty. At this time, the request parameter set of the first Web API is directly added to apiStdReq as the initial data of apiStdReq, and the return parameter set of the first Web API is directly added to apiStdRes as the initial data of apiStdReq;

[0075] Step 3.2: Standardization;

[0076] Next, the field description information of a request parameter apiReq of the next Web API in the dataset i is sent into the Word2Vec model to obtain a set of word vectors of this field description information, and then this set of word vectors is used as the feature vector of this apiReq i ;

[0077] Calculate the cosine similarity between the feature vector of apiReq i and each feature vector of apiStdReq in the standardized request parameter set apiStdReq j to obtain a set of cosine similarity values, and take the largest cosine similarity value as the semantic similarity value sim_score between apiReq i and apiStdReq j ; max ;

[0078] When sim_score max >= 0.9, then establish the mapping relationship between this apiReq i and this apiStdReq j ; when sim_score max < 0.9, then take apiReq i as a new standardized request parameter and add it to apiStdReq; finally, construct a standardized request parameter set apiStdReq for the entire Web API experimental dataset;

[0079] Similarly, perform the above processing on the return parameters of all Web APIs in the dataset to obtain a standardized return parameter set apiStdRes.

[0080] Step 3.3: Repeat Step 3.2 until all Web APIs in the experimental dataset are processed;

[0081] Step 4: Classify the type of each request parameter apiReq of the Web APIs in the experimental dataset i ;

[0082] All Web API request parameters are divided into two major categories and seven subtypes. The first major category is divided into four types: "required or not", "determines whether the call is successful", "affects some return parameters", and "depends on some request parameters". The second major category is divided into three types: "must be provided by developers", "can be filled with default values", and "can be filled with false values". A request parameter can belong to multiple types at the same time;

[0083] Step 4.1: Determine whether apiReq i belongs to the types of "required or not" and "can be filled with default values";

[0084] Specifically: Read the required or not field and example field of apiReq i from the database; if the value of the required or not field is

[0085] "Y", then apiReq i is of the type "required or not"; if the example field has a value, that is, it is not empty, then apiReq i belongs to the type "can be filled with default values";

[0086] Step 4.2: Determine whether apiReq i belongs to the types of "determines whether the call is successful" and "must be provided by developers";

[0087] After analyzing the documentation and making real calls to more than 1,200 Web APIs, a total of 6 request parameters that play a decisive role in the Web API calls are summarized, such as: application key, user's permission signature, etc. These 6 requests form the set determinedReq, and 17 request parameters that must be provided by developers are determined, such as: target language, keywords entered by the user, destination, etc. These 17 requests form the set depReq;

[0088] If apiReq i belongs to determinedReq, then it belongs to the type "determines whether the call is successful"; if apiReq i belongs to depReq, then it belongs to the type "must be provided by developers";

[0089] Step 4.3: Determine whether apiReq i belongs to the types of "affects some return parameters" and "depends on some request parameters";

[0090] Read the dependency relationship of apiReq i from the database and determine whether it belongs to the types of "affects some return parameters" and "depends on some request parameters";

[0091] Step 4.4: If apiReqi If it does not belong to any of the types in steps 4.1, 4.2, and 4.3, it is automatically classified into the type "can be filled with false values".

[0092] Step 5: Convert the request data provided by the user to obtain the complete request parameters and their values that can be used to successfully call the candidate Web APIs.

[0093] Step 5.1: Standardize the request data provided by the user and the specified return data.

[0094] Use the Word2Vec model to calculate the semantic similarity between the request data userReq provided by the developer and the specified return data userRes, and the standardized request parameter set stdReq and the standardized return parameter set stdRes respectively, to obtain the standardized request parameter userStdReq corresponding to the request data provided by the developer, and the standardized return parameter userStdRes corresponding to the specified return data.

[0095] Step 5.2: Obtain the Web API candidate set API_Candidates.

[0096] Compare the userStdRes obtained in the previous step with the standardized return parameter apiStdRes corresponding to each Web API. If apiStdRes completely contains userStdRes, add the Web API corresponding to this apiStdRes to the Web API candidate set.

[0097] Step 5.3: Construct the CQ for each candidate Web API.

[0098] For each request parameter of each candidate Web API, if it belongs to one of the three types of "whether it is required", "determines whether the call is successful", and "affects some return parameters", directly add it to the CQ; if it belongs to the type of "depends on some request parameters", add the request parameters it depends on to the CQ.

[0099] Step 5.4: Fill in the CQ values.

[0100] For each request parameter cq in CQ, first check whether the developer has provided this cq. If not, add this cq to the set of missing request parameters CQ_missing. For each cqm in CQ_missing, if its type is "must be provided by the developer", then the developer must be asked for data again; if its type is "can be filled with default values", then obtain the value of this cqm from the maintained request parameter default value table for filling; if its type is "can be filled with false values", then obtain the value of this cqm from the maintained request parameter false value table for filling;

[0101] The conversion of request parameters is completed, obtaining the CQ and its values for each candidate Web API.

[0102] Evaluation metrics and their values;

[0103]

[0104] Conversion success rate: The ratio of successfully converting the incomplete request parameters provided by the user into CQ. For example, there are 100 groups of incomplete request parameters. After passing through the request parameter conversion algorithm, 93 groups of request parameters can be successfully converted into CQ.

Claims

1. A method for converting request parameters for WebAPI calls, characterized in that, Specifically, it includes the following steps: Step 1: Construct a WebAPI experimental dataset; Step 2: Classify the constructed WebAPI experimental dataset; Step 3: Standardize each native request parameter and native return parameter of each WebAPI in the WebAPI experimental dataset; Use the Word2Vec model to convert the processing of text content into vector operations in space by converting words into vector forms, and then calculate the similarity on the vector space to represent the semantic similarity of the text; Step 4: Classify the type of each request parameter apiReq of the WebAPI in the experimental dataset i ; All WebAPI request parameters are divided into two major categories and seven subcategories; the first major category is divided into four types: "required or not", "determine whether the call is successful", "affect some return parameters", and "depend on some request parameters"; the second major category is divided into three types: "must be provided by developers", "can be filled with default values", and "can be filled with false values"; a request parameter can belong to multiple types at the same time; Step 5: Convert the request data provided by the user to obtain the complete request parameters and their values that can be used to successfully call the candidate WebAPI; Step 5.1: Standardize the request data and the specified return data provided by the user; Step 5.2: Obtain the WebAPI candidate set API_Candidates; Step 5.3: Construct the CQ of each candidate WebAPI; Step 5.4: Fill the CQ value; The request parameter conversion ends, and the CQ and its value of each candidate WebAPI are obtained.

2. The request parameter conversion method for WebAPI calls according to claim 1, wherein The WebAPI experimental dataset described in Step 1 contains multiple structured WebAPI experimental data, and the WebAPI experimental data includes a request parameter set, a return parameter set, and basic information; Among them, the request parameter set contains several request parameters, and a request parameter contains several fields, specifically including: parameter name field, parameter type field, parameter meaning field, required or not field, and example field; the return parameter set contains several return parameters, and a return parameter contains several fields, specifically including: parameter name field, parameter type field, parameter meaning field, and example field; the basic information includes: function description of the Web API, call address, call method, and call example.

3. A request parameter conversion method for WebAPI calls according to claim 1, characterized in that Step 1 is specifically: Step 1.1: Crawl and filter WebAPI description documents; First, crawl a large number of WebAPI description documents from the developer platforms provided by major SaaS manufacturers, and then screen out high-quality and complete WebAPI description documents through keyword matching methods; The screening by keyword matching is specifically: preset the keywords to be matched, including: interface basic information, request address, request parameters, request examples, return parameters, response examples. If a WebAPI description document contains all keywords, then retain this description document; If a WebAPI description document does not completely contain all keywords, then eliminate this description document; Step 1.2: Construct a dataset; From the description documents of the screened Web APIs, store the data of each Web API description document in the database in the form of structured data; at the same time, according to the parameter descriptions in the development documents, store the dependency relationships between request parameters and the dependency relationships between request parameters and return parameters in the database as well.

4. A request parameter conversion method for WebAPI calls according to claim 1, characterized in that, Step 2: Classify each Web API in the dataset according to its function description through the Naive Bayes algorithm.

5. A method for converting request parameters for WebAPI calls according to claim 1, characterized in that, Step 3 is specifically as follows: Step 3.1: Initialization; Before initialization, apiStdReq is empty. At this time, directly add the request parameter set of the first Web API to apiStdReq as the initial data of apiStdReq, and directly add the return parameter set of the first Web API to apiStdRes as the initial data of apiStdReq; Step 3.2: Standardization; Next, send the field description information of a request parameter apiReq of the next WebAPI in the dataset i into the Word2Vec model to obtain a set of word vectors for this field description information, and then use this set of word vectors as the feature vectors of this apiReq i ; Calculate the eigenvector of apiReq i and the cosine similarity between the eigenvector of each apiStdReq in the standardized request parameter set apiStdReq j to obtain a set of cosine similarity values, and take the maximum cosine similarity value as the semantic similarity value sim_score i between apiReq j and apiStdReq max ; When sim_score max >= 0.9, then establish the mapping relationship between this apiReq i and this apiStdReq j ; when sim_score max < 0.9, then use apiReq i as a new standardized request parameter and add it to apiStdReq; finally, construct a set of standardized request parameters apiStdReq for the entire Web API experimental dataset; Similarly, perform the above processing on the return parameters of all Web APIs in the dataset to obtain a standardized return parameter set apiStdRes; Step 3.3: Repeat Step 3.2 until all Web APIs in the experimental dataset are processed.

6. A request parameter conversion method for WebAPI calls according to claim 1, characterized in that, Step 4 is specifically as follows: Step 4.1: Determine whether apiReq i belongs to the types of "whether mandatory" and "can be filled with default values"; Specifically: Read apiReq from the database i for its required and example fields; if the value of the required field is "Y", then apiReq i is of the "required" type; if the example field has a value (i.e., is not empty), then apiReq i belongs to the "can be filled with default values" type; Step 4.2: Determine whether apiReq i belongs to the types of "Determine whether the call is successful" and "Must be provided by the developer"; After analyzing the description documents and making real calls to multiple Web APIs, a number of request parameters that play a decisive role in the call to Web APIs are summarized. They form the set determinedReq, and a number of request parameters that must be provided by developers are determined. They form the set depReq; If apiReq i belongs to determinedReq, then it belongs to the type "Determine whether the call is successful"; If apiReq i belongs to depReq, then it belongs to the type "Must be provided by developers"; Step 4.3: Determine whether apiReq i belongs to the types of "affecting some return parameters" and "depending on some request parameters"; Read apiReq from the database i for its dependencies and determine whether it belongs to the types of "affecting partial return parameters" or "depending on certain request parameters"; Step 4.4: If apiReq i does not belong to any of the types in Steps 4.1, 4.2, and 4.3, it is automatically classified into the type "can be filled with false values".

7. A method for converting request parameters for WebAPI calls according to claim 1, characterized in that Steps 5.1 to 5.4 specifically include: Step 5.1: Standardize the request data and the specified return data provided by the user; Use the Word2Vec model to calculate the semantic similarity between the request data userReq and the specified return data userRes provided by the developer and the standardized request parameter set stdReq and the standardized return parameter set stdRes respectively, to obtain the standardized request parameters userStdReq corresponding to the request data provided by the developer and the standardized return parameters userStdRes corresponding to the specified return data; Step 5.2: Obtain the Web API candidate set API_Candidates; According to the userStdRes obtained in the previous step, compare it with the standardized return parameters apiStdRes corresponding to each Web API. If apiStdRes completely contains userStdRes, add the Web API corresponding to this apiStdRes to the Web API candidate set; Step 5.3: Construct the CQ of each candidate Web API; For each request parameter of each candidate Web API, if it belongs to one of the three types of "whether it is required", "determines whether the call is successful", and "affects some return parameters", directly add it to the CQ; if it belongs to the type of "depends on some request parameters", add the request parameters it depends on to the CQ; Step 5.4: Fill the CQ value; For each request parameter cq in CQ, first determine whether the developer has provided this cq. If not, add this cq to the set of missing request parameters CQ_missing. For each cqm in CQ_missing, if its type is "must be provided by the developer", then the developer must be asked for data again; if its type is "can be filled with default values", then obtain the value of this cqm from the maintained request parameter default value table for filling; if its type is "can be filled with false values", then obtain the value of this cqm from the maintained request parameter false value table for filling; The request parameter conversion is completed, obtaining the CQ and its values for each candidate WebAPI.

Images