WO2011127863A2

WO2011127863A2 - Method and device for calling open application programming interface (openapi)

Info

Publication number: WO2011127863A2
Application number: PCT/CN2011/074424
Authority: WO
Inventors: 金洪波; 颜友亮; 齐泉; 陈世展
Original assignee: 华为技术有限公司
Priority date: 2011-05-20
Filing date: 2011-05-20
Publication date: 2011-10-20
Also published as: CN102203736A; CN102203736B; WO2011127863A3

Abstract

A method and a device for calling an Open Application Programming Interface (OpenAPI) are provided. The method includes: obtaining a target OpenAPI method corresponding to a calling request of a user; providing a parameter list corresponding to the target OpenAPI method to the user so as to obtain the parameter information of the target OpenAPI method; processing the calling for the target OpenAPI method according to the parament information and the calling rule matching with the target OpenAPI method. By adopting this technical solution, calling different OpenAPIs using a uniform mode can be realized, and the calling efficiency is improved.

Description

Open application programming interface calling method and device

Technical field

The embodiments of the present invention relate to a programming interface technology, and in particular, to an open application programming interface (Open Application Programming Interface; Open API) calling method and device. Background technique

At present, there are a large number of open OpenAPIs (OpenAPIs) in the Internet. By learning the documentation of OpenAPI, users can call these OpenAPIs to implement the corresponding functions.

Ah

3匕.

However, the communication protocols and calling methods used by different OpenAPIs are different. For users who directly call a function in OpenAPI, and for Web application developers who use the existing OpenAPI for secondary development, not only need to learn the documentation of OpenAPI to understand the function and structure of OpenAPI as a whole, but also need to The communication mechanism adopted by the OpenAPI is learned to basically call the OpenAPI method before calling the OpenAPI and obtaining the open capability provided by the OpenAPI.

It can be seen from the above that due to the different communication mechanisms adopted by different OpenAPIs, the process of calling OpenAPI to implement openness is extremely inconvenient and inconvenient, and the efficiency of calling OpenAPI is low. At the same time, it is impossible to implement a different calling API by using a unified calling process. Call. Summary of the invention

The embodiment of the invention provides an open application programming interface calling method and device, which are used to implement different calling OpenAPI in a unified manner, and improve the efficiency of calling OpenAPI.

An embodiment of the present invention provides an open application programming interface OpenAPI calling method, including: acquiring a target OpenAPI method corresponding to a user's calling request; Providing the user with a parameter list corresponding to the target OpenAPI method, to obtain parameter information of the target OpenAPI method;

The target OpenAPI method is called according to the parameter information and a calling rule adapted to the target OpenAPI method.

An embodiment of the present invention provides an open application programming interface OpenAPI calling device, including: a method obtaining unit, configured to acquire a target OpenAPI method corresponding to a user's calling request, and a parameter obtaining unit, configured to provide the user with the user Determining a parameter list corresponding to the target OpenAPI method, to obtain parameter information of the target OpenAPI method;

And a calling unit, configured to invoke the target OpenAPI method according to the parameter information and a calling rule adapted to the target OpenAPI method.

The method and device for calling an open application programming interface of the embodiment of the present invention obtain the parameter information corresponding to the target OpenAPI method and the target OpenAPI method, and then call the target OpenAPI method by using a calling rule adapted to the target OpenAPI method, which may be adopted. The unified calling process implements calls to different OpenAPIs, which simplifies the calling process and improves the efficiency of calling OpenAPI. DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, a brief description of the drawings to be used in the description of the embodiments will be briefly made. It is obvious that the drawings in the following description are the present invention. For some embodiments, other drawings may be obtained from those of ordinary skill in the art without departing from the drawings.

FIG. 1 is a flowchart of a method for calling an OpenAPI according to an embodiment of the present invention;

2A is a flowchart of an embodiment of a step 101 according to an embodiment of the present invention; FIG. 2B is a schematic diagram of another embodiment of step 101 according to an embodiment of the present invention; A flowchart of still another embodiment of the step 101 is provided. FIG. 2D is a flowchart of an embodiment of the step 10c3 according to an embodiment of the present invention; FIG. 2E is another embodiment of the step 10cl3 according to an embodiment of the present invention. Flow chart of an embodiment; FIG. 3 is a flowchart of an implementation of step 103 according to an embodiment of the present invention;

4 is a flowchart of a method for calling an OpenAPI according to another embodiment of the present invention;

FIG. 5 is a flowchart of a calling method when a target OpenAPI method adopts a Rest protocol according to an embodiment of the present invention;

6 is a flowchart of a calling method when a target OpenAPI method adopts a Soap protocol according to an embodiment of the present invention;

FIG. 7 is a flowchart of a calling method when a target OpenAPI method adopts an Ajax protocol according to an embodiment of the present invention;

FIG. 8 is a schematic structural diagram of an OpenAPI calling device according to an embodiment of the present invention;

FIG. 9 is a schematic structural diagram of an OpenAPI calling device according to another embodiment of the present invention. detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is a partial embodiment of the invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

FIG. 1 is a flowchart of a method for calling an OpenAPI according to an embodiment of the present invention. As shown in FIG. 1, the method in this embodiment includes:

Step 101: Obtain a target OpenAPI method corresponding to a user's call request.

Specifically, the OpenAPI calling device provides an interface for obtaining a user call request for the user to input its call request. After the user inputs the call request, the OpenAPI calling device obtains the corresponding OpenAPI method by querying the OpenAIP information base according to the call request.

Among them, the OpenAPI information library stores a large amount of OpenAPI information, and these OpenAPI information can be obtained by manual pre-collection. In addition, in combination with each OpenAPI, the OpenAPI method is included, and each OpenAPI method has corresponding parameter information, so in this embodiment, according to the layering of OpenAPI Point, OpenAPI information is stored as a list. That is, the OpenAPI repository, the method list, and the parameter list are included in the OpenAPI repository. The OpenAPI list includes a large number of OpenAPI information, wherein each OpenAPI information mainly includes an OpenAPI identifier (ID), an OpenAPI function description information, an OpenAPI call address, a used communication protocol, and the like. The method list includes information about the OpenAPI method corresponding to each OpenAPI in the OpenAPI list, and there is a mapping relationship between the OpenAPI list and the method list; the information of the OpenAPI method mainly includes the ID of the OpenAPI method, function description information, and the like. The parameter list includes the parameter information corresponding to each OpenAPI method in the method list, that is, the information required to call an OpenAPI method, and there is a mapping relationship between the parameter list and the method list.

It can be seen from the above that since a large amount of OpenAPI information is stored in advance, the OpenAPI calling device can search for a large API method in accordance with the user's call request in a large number of OpenAPI methods, thereby improving the success rate of the user calling the OpenAPI method.

The OpenAPI calling device can provide a calling interface to the user, so that the user inputs the calling request through the calling interface, and finally obtains the target OpenAPI method.

Step 102: Provide a user with a parameter list corresponding to the target OpenAPI method to obtain a target

Parameter information of the OpenAPI method.

Specifically, the OpenAPI calling device searches the OpenAPI information base according to the target OpenAPI method to obtain a corresponding parameter list, and provides a parameter list to the user through a calling interface, so that the user inputs the corresponding parameter information. Preferably, the calling interface is the same calling interface as the calling interface of step 101.

When the user inputs the parameter information according to the parameter list, the OpenAPI call device can obtain the parameter information. The parameter list corresponding to different OpenAPI methods is not the same, and the parameter information obtained by the OpenAPI calling device is also different.

Step 103: Call the target OpenAPI method according to the parameter information and the calling rule that is adapted to the target OpenAPI method.

Among them, different OpenAPIs use different communication protocols, for example, may use a representation state Representational State Transfer (referred to as: Rest) protocol, Simple Object Access Protocol (Sole) or Ajax (Asynchronous JavaScript and XML) protocol. The calling process for each protocol is different. In order to solve the problem that the user needs to learn the OpenAPI method under different protocols, it is necessary to learn different communication mechanisms to understand the corresponding calling process, and then call the OpenAPI method through different calling processes. In this embodiment, the OpenAPI calling device is pre-stored with various The calling protocol adapted to the communication protocol, when the OpenAPI calling device needs to call the OpenAPI method, selects an appropriate calling rule according to the communication protocol adopted by the OpenAPI method, and automatically completes the process of calling the OpenAPI method to the OpenAPI server according to the calling rule and the parameter information. , without the user having to learn the communication protocol.

Among them, the OpenAPI server refers to a server that stores a large number of OpenAPIs, which are usually deployed by the OpenAPI provider.

In the OpenAPI calling method of the embodiment, after obtaining the parameter information corresponding to the target OpenAPI method and the target OpenAPI method, the OpenAPI calling device invokes the target OpenAPI method by using a calling rule adapted to the target OpenAPI method, and implements the target OpenAPI method. The use of a unified call flow to achieve calls to different OpenAPIs simplifies the calling process and improves the efficiency of calling OpenAPI.

The following embodiments of the present invention provide specific implementations of several steps 101. FIG. 2A is a flowchart of an embodiment of a step 101 according to an embodiment of the present invention. As shown in FIG. 2A, the implementation of this embodiment includes:

Step 10al: Receive a first call request sent by the user.

Specifically, when the user needs to invoke the OpenAPI method, the OpenAPI calling tool can initiate a call request (ie, the first call request) to the OpenAPI calling device of this embodiment. In this embodiment, the user's invocation request may not include any information related to the OpenAPI, so that the user can generate and initiate a call request.

Step 10a2: Provide an OpenAPI list to the user according to the first call request, so that the user selects the target OpenAPI. After the OpenAPI calling device obtains the calling request of the user, the OpenAPI information base is queried according to the calling request, and the entire OpenAPI list in the OpenAPI information base is provided to the user. Specifically, the OpenAPI calling device provides the OpenAPI list to the user through the calling interface. The OpenAPI list includes information of multiple OpenAPIs; after seeing the OpenAPI list, the user selects an OpenAPI (ie, target OpenAPI) according to his own needs. After the user selects OpenAPI, the OpenAPI call device gets the target OpenAPI.

Step 10a3: Obtain a method list corresponding to the target OpenAPI, and provide the method list to the user for selection by the user.

After the OpenAPI calling device obtains the target OpenAPI, it queries the OpenAPI information base according to the target OpenAPI to obtain a list of methods corresponding to the target OpenAPI. For example, by the ID of the target OpenAPI, get a list of methods indexed by that ID. The method list is then provided to the user via the call interface. The method list includes information about multiple OpenAPI methods, and the user selects an OpenAPI method (ie, the target OpenAPI method) according to his or her own needs.

Step 10a4: Obtain a target OpenAPI method according to a result of the user selection.

Specifically, after the user selects, the OpenAPI calling device obtains the target OpenAPI method. After that, step 102 and step 103 are performed to complete the call to the target OpenAPI method.

In this embodiment, the user only needs to issue a call request to call OpenAPI, and does not need to indicate any information of the OpenAPI to be called. The OpenAPI calling device provides the corresponding information to the user through the calling interface, and the user only needs to call the unified process of the device according to the OpenAPI. The operation can be performed, and the user is enabled to call different OpenAPI methods through a unified process, thereby improving the calling efficiency.

FIG. 2B is a schematic diagram of another embodiment of step 101 according to an embodiment of the present invention. As shown in FIG. 2B, the embodiment of this embodiment includes:

Step 10b1: Receive a second call request sent by the user, where the second call request includes an OpenAPI keyword.

Specifically, when the user needs to invoke the OpenAPI method, the OpenAPI calling tool may initiate a call request (ie, a second call request) to the OpenAPI calling device of the embodiment, where the second The call request contains the OpenAPI keyword. The OpenAPI keyword is used to identify the OpenAPI that the user wants to call; the OpenAPI keyword may be one of the OpenAPI information stored in the OpenAPI list, so that the OpenAPI calling device can obtain the corresponding OpenAPI according to the OpenAPI keyword. For example: The OpenAPI keyword can be an OpenAPI ID or a call address.

Step 10b2: Query the OpenAPI list according to the OpenAPI keyword to obtain the target OpenAPI corresponding to the OpenAPI keyword.

The OpenAPI calling device searches in the OpenAPI list of the OpenAPI repository according to the OpenAPI keyword to obtain an OpenAPI that conforms to the OpenAPI keyword, that is, the target OpenAPI.

Step 10b3: Obtain a method list corresponding to the target OpenAPI, and provide the method list to the user for selection by the user.

The target OpenAPI corresponds to multiple OpenAPI methods, and all OpenAPI method related information is recorded in the method list under the target OpenAPI. After the OpenAPI calling device obtains the target OpenAPI, it searches in the OpenAPI repository to obtain a list of methods under the target OpenAPI. Then, the method list is provided to the user through the calling interface, so that the user can select an OpenAPI method, that is, the target OpenAPI method.

Step 10b4: Obtain a target OpenAPI method according to the result of the user selection.

In this implementation manner, the user sends a call request carrying the OpenAPI keyword directly to the OpenAPI calling device through the OpenAPI calling tool, so that the OpenAPI directly obtains the target OpenAPI, which reduces the interaction between the subsequent OpenAPI calling device and the user, and the user and the OpenAPI call device. The acquisition of the target OpenAPI method can be completed only once, and the efficiency of obtaining the target OpenAPI is improved.

It is explained that the OpenAPI calling method implemented in conjunction with FIG. 2A or FIG. 2B can be implemented by a functional unit in the calling device of the OpenAPI, which is specifically encapsulating the original OpenAPI, and the OpenAPI is guaranteed during the development process. Time interface consistency to provide users with a simple The easy-to-use call interface allows the user to specify the OpenAPI method to be called, and the OpenAPI method can automatically initiate a call to the OpenAPI method after the parameter information is filled in. Based on the specific function of the functional unit, the functional unit is referred to as a directly selected calling unit.

In addition, in the above Figs. 2A and 2B, the functions of the OpenAPI calling device can be divided into different functional levels. For example: The operation of selecting the target OpenAPI or selecting the target OpenAPI method is done by the user (User), and the operation of providing the user with an OpenAPI list, a method list or a parameter list can be considered as being done by the OpenAPI calling device's view layer. Querying the OpenAPI repository, the operation of obtaining an OpenAPI list, a method list, or a parameter list can be considered as being performed by the control layer of the device invoked by OpenAPI. The OpenAPI list, method list, and parameter list in the OpenAPI repository can be thought of as being stored in the model layer of the OpenAPI calling device.

In addition, the operation of calling the target OpenAPI method according to the calling rules can also be considered as being done by the control layer of the OpenAPI calling device.

FIG. 2C is a flowchart of still another embodiment of step 101 according to an embodiment of the present invention. As shown in FIG. 2C, the embodiment of this embodiment includes:

Step 10cl: Obtain an OpenAPI function parameter corresponding to the call request.

Specifically, when the user needs to call the OpenAPI method, the function call request is sent to the OpenAPI calling device through its OpenAPI calling tool. The function call request includes OpenAPI function parameters, which are used to identify the functions that the user needs to perform the OpenAPI method, but do not limit which OpenAPI method. The OpenAPI calling device receives the function call request, and then parses the function call request to obtain the OpenAPI function parameters therein. Specifically, the OpenAPI calling device may parse the function call request according to the format of the function call request that is pre-agreed by the user, and obtain the OpenAPI function parameter from the corresponding location.

Step 10c2: Obtain an OpenAPI method set according to the OpenAPI function parameter. The OpenAPI method set includes multiple OpenAPI methods corresponding to OpenAPI function parameters.

After the OpenAPI calling device obtains the OpenAPI function parameters, the OpenAPI information base is queried according to the obtained OpenAPI function parameters, mainly according to the OpenAPI function parameters. Look in the OpenAPI list and method list and get all OpenAPI methods that implement the functionality described by the OpenAPI function parameters. Among them, the obtained OpenAPI methods with the same function are stored in the OpenAPI method set. The various OpenAPI methods in the OpenAPI method set can come from different OpenAPIs or can be written using different communication protocols, but with the same parameter list.

Step 10c3: According to the OpenAPI method, the Quality of Service (Qos) attribute value of each OpenAPI method is centralized, and the target OpenAPI method is obtained.

Among them, the OpenAPI information base also includes the Qos attribute value of each OpenAPI method. The Qos attribute value can include a subjective Qos attribute and/or an objective Qos attribute. The subjective Qos attribute mainly reflects the user's evaluation of OpenAPI. The objective Qos attribute mainly reflects some performances in the OpenAPI call process. The subjective Qos attribute can include any one or combination of the following: Usability, Correctness, Performance/Price, or Subjective Security. Among them, ease of use is used to reflect whether the process of calling OpenAPI is simple and whether the returned result is easy to understand. Correctness is used to evaluate whether the result obtained after calling OpenAPI is the result expected by the user. The price-to-price ratio is the ratio of the actual application value of an OpenAPI to the cost of the user calling the OpenAPI. Subjective security refers to the evaluation of whether the OpenAPI is safe after the user calls OpenAPI. In addition, weighted averaging processing can be performed on the above various subjective Qos attributes to obtain a comprehensive subjective evaluation value. The objective Qos attribute may include any one or a combination of the following: encryption security, response time (Response Time), availability (Availability), or stability (Stability). Among them, encryption security refers to whether the transmission process of the OpenAPI call is encrypted. Response time is the degree to which OpenAPI is called, that is, the time difference from the user-initiated call to the user's return. Availability is used to evaluate whether the current OpenAPI is available and can be characterized by the ratio of users successfully calling OpenAPI. Stability can be expressed in Mean Time between Failures (MTBF), which is the average working time between failures of OpenAPI calls.

In this embodiment, the above Qos attribute value of each OpenAPI method is obtained in advance. Specifically, the objective Qos attribute value can be obtained by monitoring the process of calling the OpenAPI method, for example: The detection program can record the objective information including the response time and availability of the OpenAPI method. To get the value of the Qos attribute. The subjective Qos attribute value can be obtained by calling the user's evaluation after the OpenAPI method is finished. For example: After the call ends, the user is required to submit subjective evaluation information including correctness, ease of use, and cost performance. In other words, the value of the Qos property of the OpenAPI method is gradually collected during the called process.

Among the various Qos attribute values, the larger the value of some Qos attributes, the higher the performance of OpenAPI, such as availability; the smaller the value of some Qos attributes, the higher the performance of OpenAPI, such as response time. The larger the value of the Qos attribute is, the better the performance of the OpenAPI is. The Qos attribute is called the incremental QoS attribute, and the value is called the incremental QoS attribute value. The smaller the QoS attribute value is, the better the OpenAPI performance is. The Qos attribute is called the decrement type Qos attribute, and its value is called the decrement type Qos attribute value. For the convenience of calculation, in the embodiment, the selection device normalizes various Qos attribute values, and generates a user applicability value, and evaluates the performance of the OpenAPI by using the user applicability value, and is based on each OpenAPI. The user applicability value of the method is used to select the target OpenAPI method.

Specifically, the OpenAPI calling device normalizes the incremental Qos attribute value according to the formula (1). :≠0

k ―:„ k

v(2) = maxgr-ming" ( 1 ) maxg -ming =0

i=l i=l

The OpenAPI calling device normalizes the decremented Qos attribute value according to formula (2) - maxg -e „ „

^ ^ ~ , maxQ -mmQ ≠0

v(2) = maxe-mine ^i=li=l (2)

i=li=l maxg -ming' where represents the kth Qos attribute value of the first OpenAPI method; v(g) represents the kth normalized Qos attribute value of the first OpenAPI method; n represents the OpenAPI method set The number of OpenAPI methods, i=\ ...n; k=l ...m , m represents the number of Qos attributes of each OpenAPI method. For example: When the QoS attribute corresponding to each OpenAPI method includes both ease of use, correctness, cost performance, security, response time, availability, and stability, it is 7.

Further, after the normalization process, the OpenAPI calling device performs a weighted averaging process on the normalized Qos attribute value according to the formula (3) to generate a user applicability value.

Where ^ represents the weight value of the ^: normalized Qos attribute value of each OpenAPI method; in this embodiment, the weight value is preset, and for each OpenAPI method, the w _k is the same, but is not limited to this; represents the user suitability value corresponding to the first OpenAPI method.

An implementation manner of the step 10c3 is as follows: The OpenAPI calling device selects an OpenAPI method with the largest user applicability value from the multiple OpenAPI methods in the OpenAPI method set as the target OpenAPI method. The implementation is simple and easy to implement, and the selected OpenAPI method is the best OpenAPI method, and the user can obtain a higher quality service after calling the target OpenAPI method.

As shown in FIG. 2D, another embodiment of step 10c3 includes:

Step 10c31: Assign a selection probability to each OpenAPI method according to the user suitability value corresponding to each OpenAPI method.

Among them, the OpenAPI calling device allocates different selection probabilities for each OpenAPI, and ensures that the selection probability of the OpenAPI method with good performance is large. That is, if the user value of the OpenAPI method is larger, the probability of the selection that the OpenAPI calling device assigns to it is greater. The sum of all selection probabilities assigned by the OpenAPI calling device is 1. Suppose there are n OpenAPI methods, arranged in order from small to large: apiidl , apiid2 , apiidi , apiidn , the corresponding selection probabilities are pi , p2 , pi , n , where pl+p2+....+ Pi+...+pn=l. The n selection probabilities will be divided into n+1 probability intervals.

Step 10c32, generating a random number.

Specifically, the OpenAPI calling device generates a random number between 0-1 according to a certain algorithm. Step 10c33: Select a target OpenAPI method from a plurality of OpenAPI methods according to the random number and the selection probability.

Specifically, the OpenAPI calling device sorts the selection probabilities in ascending order; then, compares the random numbers with the sorted selection probabilities, until the first selection probability greater than the random number is compared, and the first one is selected. The OpenAPI method corresponding to the selection probability of the random number is used as the target OpenAPI method. That is to say, the OpenAPI calling device determines in which probability interval the random number appears, takes the OpenAPI method corresponding to the upper limit of the probability interval, and uses the OpenAPI method as the target OpenAPI method.

This embodiment can ensure that the OpenAPI method with higher probability is more likely to be selected by generating a random number between 0-1 and selecting the target OpenAPI method according to the random number and the selection probability assigned to the OpenAPI method. The higher the performance, the higher the probability that the OpenAPI method will be selected, and the possibility that each OpenAPI method will be selected.

Further, after selecting the target OpenAPI method, the OpenAPI calling device performs steps 102 and 103 to call the target OpenAPI method to the OpenAPI server; and determines whether the OpenAPI server returns the calling result. If the judgment result is no, indicating that the target OpenAPI method fails, the target OpenAPI method is removed from the OpenAPI method set, and step 10c3 is re-executed to regain the target OpenAPI method. If the judgment result is yes, it indicates that the calling target OpenAPI method is successful, the call result is returned to the user, and the OpenAPI call operation is ended.

The implementation shown in FIG. 2C may be implemented by another functional unit of the OpenAPI calling device, which specifically provides an input parameter to the directly selected calling unit, and invokes the direct selection of the calling unit to implement the call to the OpenAPI method. Once the user has determined an abstract function that can satisfy his own needs, the functional unit allows the user to directly input the OpenAPI function parameters, and then automatically obtains multiple OpenAPI methods having the functions described by the OpenAPI function parameters according to the OpenAPI function parameters, and According to the Qos attribute, the OpenAPI method with better performance (that is, the service quality is better) is selected for the user to call, and if the selected target OpenAPI method is unavailable (that is, the call is not successfully succeeded), the user is selected from the OpenAPI method set and then re-selected for the user. Until the user gets the tone Use the results so far. The above operation process is transparent to the user, and the user only needs to send a call request with the OpenAPI function parameter, no matter which OpenAPI method is finally called, the entire calling process is the same for the user, and the user does not need to care. The communication protocol used by each OpenAPI method simplifies the user's calling process and improves the calling efficiency. Based on the specific function of the functional unit, the functional unit is referred to as a one-key calling unit. The one-click calling unit is implemented based on calling the directly selected calling unit.

In the embodiment shown in FIG. 2C, the user only needs to send a call request once to call the device through OpenAPI to obtain a better OpenAPI method, and does not need to issue a call request to different devices multiple times, thereby improving the user's call to the OpenAPI method. effectiveness.

Further, as shown in FIG. 2E, another implementation manner of the step l0cl includes:

Step 10cl: Receive an application call request sent by the user, where the application call request includes application description information.

Specifically, when the user needs to call the OpenAPI method to implement an application, the application call request is sent to the OpenAPI calling device through its OpenAPI calling tool. The users here mainly refer to the development users who develop new applications or new systems based on the OpenAPI method. The application call request includes a description of the system or application that the user needs to complete through the OpenAPI method. For example: Take the combination application of the school introduction and the map as an example. The combined application needs to obtain a map centered on a certain coordinate (ie, a certain location), and then obtain the school information near the coordinate location, and the combination of the two is displayed together. . Two functional information is involved in the combined application, one is to obtain a map centered on a certain location, and the other is to obtain a school-centered introduction. When the user needs to implement the combination application of the school introduction and the map through the OpenAPI method, the user only needs to send an application call request carrying the "school introduction and map combination and location A" information to the OpenAPI calling device, which specific OpenAPI method is used to implement the application. The function is determined by the OpenAPI calling device according to the two function information obtained by the parsing. Among them, the combination application of the school introduction and the map is only an example of the application description information.

Step 10cl2: Perform function parsing on the application description information to obtain OpenAPI function parameters.

After receiving the application call request, the OpenAPI calling device parses the application call request. Take the application description information, and then perform function parsing on the application description information to obtain OpenAPI function parameters. For example: OpenAPI calls the device to perform functional analysis on "School introduction and map combination and location A", and obtains two OpenAPI function parameters such as "Get map centered on location A and get school introduction centered on location A".

Afterwards, the OpenAPI invoking device executes step 10c32, performs a search in the OpenAPI information base according to the above OpenAPI function parameters, and finally finds an OpenAPI method set having a map function centered on the location A and an introduction to the school centered on the location A. A set of OpenAPI methods for functionality. Similarly, in these method sets, each OpenAPI method can be written using a different communication protocol, or it can belong to different OpenAPL.

Then, the OpenAPI calling device performs step 10c33, respectively, from the above-mentioned OpenAPI method set with the map function centered on the location A and the OpenAPI method with the school introduction function centered on the location A, and the acquisition is obtained by the location A. The central OpenMap method of the map function and the target OpenAPI method with the ability to acquire the school-introduction function centered on location A. Among them, the process of obtaining the target OpenAPI method with the function of acquiring the map A-centered map and the process of obtaining the target OpenAPI method with the location introduction function centered on the location A are the same and independent.

The embodiment shown in FIG. 2E can be implemented by another functional unit of the OpenAPI calling device, which is mainly implemented by the application developer to invoke the target OpenAPI method on the basis of calling a key calling unit and directly selecting the calling unit. The completed application is implemented by a variety of OpenAPI methods, and provides the user with a unit that calls the interface. Since the other functional unit combines the various OpenAPI methods to form a richer application, the functional unit is referred to as a mashup call unit.

In this embodiment, the user only needs to input the application call request to implement the call of different OpenAPI methods, and the user does not need to care about the communication protocol used by each OpenAPI method, and has the advantages of simple call and high efficiency.

In addition, in this embodiment, the OpenAPI calling device is also applied to the application developer (for example, the Web should Using the developer) provides an ability for application developers to invoke various OpenAPI methods to develop new mashup applications in a simple, efficient, and unified way to provide new business functionality. That is, the mashup calling unit for implementing the embodiment can be implemented as a platform on which application developers are allowed to share function codes (ie, various OpenAPI methods), and the platform can also provide retrieval and submission. , download and other functions to achieve maximum code reuse.

In the directly selected call unit, the one-click call unit, and the mashup call unit described above, the Mashup call unit is the most granular, because a mashup application may incorporate several different OpenAPI methods. Due to this convergence, the OpenAPI calling device cannot directly evaluate the Mashup application by evaluating the QoS attribute of the OpenAPI method. Therefore, the OpenAPI calling device separately sets evaluation criteria and evaluates it in units of each Mashup application. In the evaluation criteria of the Mashup application, the main focus is on the user's evaluation. That is, after the application developer completes the Mashup call unit by calling a one-click call unit and directly selecting the call unit, after the Mashu application is implemented, the user invokes the Mashup application and returns subjective evaluation information of the Mashup application to the OpenAPI calling device. For example: In the actual implementation process, the application developer can mark the price of the points he desires when publishing the Mashup application developed by himself; when the user downloads and uses the mashup application, he needs to pay the corresponding points score and submit it after use. Evaluation information, and in order to encourage the use of users to submit evaluation information, after using the user to submit the evaluation information, the OpenAPI calling device returns a certain amount of points to the user, thereby realizing the acquisition of the Mashup application evaluation information.

It is explained here that the OpenAPI method in each of the above embodiments or embodiments includes an OpenAPI method that cannot be independently operated by the Rest protocol. Based on this, the OpenAPI calling device pre-stores the calling rules that are compatible with various protocols.

FIG. 3 is a flow chart of an embodiment of step 103 according to an embodiment of the present invention. The implementation may be implemented based on the foregoing embodiments or implementation manners. As shown in FIG. 3, the implementation manner includes:

Step 1031: Obtain a calling rule that is adapted to the target OpenAPI method according to the protocol type adopted by the target OpenAPI method. Specifically, the calling rules adapted to various communication protocols are pre-stored on the OpenAPI calling device. After the OpenAPI calling device determines the target OpenAPI method, the communication protocol used by the target OpenAPI method may be obtained from the OpenAPI list, and then the calling rule corresponding to the communication protocol is obtained.

Step 1032: Process the parameter information according to the calling rule to generate a third-party calling request.

After the OpenAPI calling device obtains the calling rule, it processes the parameter information of the target OpenAPI method to generate a third-party calling request, that is, a call request sent to a third-party OpenAPI server.

Step 1033: Send a third-party call request to the OpenAPI server to invoke the target OpenAPI method.

After generating the invocation request, the OpenAPI invoking device sends a third-party invocation request to the third-party OpenAPI server to invoke the target OpenAPI method.

In this embodiment, the OpenAPI calling device pre-stores the calling rules corresponding to various protocols, and obtains the corresponding calling rules according to the communication protocol used by the target OpenAPI method, and then invokes the target OpenAPI method, so that the user does not care about the target OpenAPI method. The communication protocol does not need to be called after learning the communication protocol, and therefore has the advantages of simple implementation and high call efficiency.

FIG. 4 is a flowchart of a method for calling an OpenAPI according to another embodiment of the present invention. The embodiment is implemented based on the embodiment shown in FIG. 1 and FIG. 3. As shown in FIG. 4, the method in this embodiment includes before step 1033:

Step 103a: Set the data format of the returned result.

Specifically, the data format of the call result supported by the OpenAPI calling device, the data format of the call result supported by the user, and the data format supported by the OpenAPI server may be different, so in order to satisfy the user's ability to recognize the returned result, in this embodiment, The OpenAPI calling device pre-sets the data format of the returned result before calling the target OpenAPI method. This is also done by the control layer of the OpenAPI calling device.

As shown in FIG. 4, after step 1033, the method further includes:

Step 1034, receiving a call result returned by the OpenAPI server, and calling according to the data format The result is formatted and the processed call result is provided to the user.

The OpenAPI calling method of this embodiment sets a data format before calling the target OpenAPI method, and formats the returned result by using the set data format after receiving the returned result, so that the user can directly receive the identifiable return result. No need for users to perform format conversion, which improves the quality of service to users.

The following embodiments of the present invention will be described in detail when the target OpenAPI adopts different communication protocols.

FIG. 5 is a flowchart of a calling method when a target OpenAPI method adopts a Rest protocol according to an embodiment of the present invention. As shown in FIG. 5, the method in this embodiment includes:

Step 501: The OpenAPI calling device acquires a target OpenAPI method according to the user's calling request.

Specifically, the step 501 can obtain the target OpenAPI method by using the implementation manner shown in any of FIG. 2A and FIG. 2D, which is determined by the user's calling request, and the detailed process is not described herein again.

Step 502: The OpenAPI calling device provides a parameter list of the target OpenAPI method to the user. Specifically, after obtaining the target OpenAPI method, the OpenAPI calling device queries the OpenAPI information library to obtain a parameter list of the target OpenAPI method, and provides the user with the calling interface.

Step 503: The user inputs the parameter information required by the target OpenAPI method according to the parameter list, and simultaneously inputs the key value of the calling key, and sends the key value to the OpenAPI calling device.

Specifically, the user inputs the parameter information on the calling interface, and at the same time inputs the encryption key required to invoke the target OpenAPI method, that is, the Key value is called, and is sent to the OpenAPI calling device by calling the submit function on the interface.

Step 504: The OpenAPI calling device receives the parameter information sent by the user and calls the Key value, queries the OpenAPI list according to the target OpenAPI method, and obtains the calling address of the target OpenAPI method.

Step 505: The OpenAPI calling device encrypts the parameter information and the called Key value to generate a third-party call request.

Specifically, the OpenAPI calling device encrypts the parameter information by calling the Key value. Generate a third-party call request. The third-party calling request under the Rest protocol is a request in a Hyper Text Mark-up Language (abbreviated as: HTML) format.

In addition, in this step, the OpenAPI calling device can also set the data format of the returned result. Step 506: The OpenAPI calling device sends a third-party calling request to the OpenAPI server according to the calling address to invoke the target OpenAPI method.

Step 507: The OpenAPI calling device receives the call result returned by the OpenAPI server, and formats the call result by using a preset data format, and then sends the result to the user.

Specifically, the OpenAPI calling device formats the call result of the Extensible Markup Language (XML) format returned by the OpenAPI server to form a call result in a format recognizable by the user.

Step 504 and step 505 are corresponding execution rules when the target OpenAPI method adopts the Rest protocol, that is, the specific implementation manner of step 1032.

In the OpenAPI calling method of the embodiment, when the target OpenAPI method adopts the Rest protocol, the calling API directly acquires the calling rule corresponding to the Rest protocol, and automatically completes the calling of the target OpenAPI method according to the calling rule, and the user does not need to learn the Rest. The communication mechanism of the protocol improves the efficiency of calling the OpenAPI method.

FIG. 6 is a flowchart of a calling method when a target OpenAPI method adopts a Soap protocol according to an embodiment of the present invention. As shown in FIG. 6, the method in this embodiment includes:

Step 601: The OpenAPI calling device acquires a target OpenAPI method according to the user's calling request.

Step 602: The OpenAPI calling device provides a parameter list of the target OpenAPI method to the user. Step 603: The user inputs parameter information required by the target OpenAPI method according to the parameter list, and sends the parameter information to the OpenAPI calling device.

The foregoing steps 601 to 603 are described in detail in steps 501 to 503, and details are not described herein again. Step 604: The OpenAPI calling device receives the parameter information sent by the user, and queries the OpenAPI list according to the target OpenAPI method, and obtains the web service description language of the Soap protocol to convert to java. (WSDL2Java) toolkit.

Step 605: The OpenAPI calling device processes the parameter information and the target OpenAPI method by using the WSDL2 Java toolkit to generate a third-party call request.

Specifically, the OpenAPI calling device uses the WSDL2 Java toolkit to make a Java interface code that is called to the Soap server (ie, the OpenAPI server), and then automatically generates a Soap client code that calls the target OpenAPI method by using the parameter information input by the user, the Soap client. The terminal code generates a third-party call request at runtime.

In addition, in this step, the OpenAPI calling device can also set the data format of the returned result. Step 606: The OpenAPI calling device sends a third-party call request to the OpenAPI server to invoke the target OpenAPI method.

Specifically, the OpenAPI calling device generates a call to the target OpenAPI method by running the Soap client code to generate and send a third-party call request to the OpenAPI server.

Step 607: The OpenAPI calling device receives the call result returned by the OpenAPI server, and formats the call result by using a preset data format, and then sends the result to the user.

Specifically, the OpenAPI calling device formats the call result returned by the OpenAPI server to form a call result in a format recognizable by the user.

Step 604 and step 605 are the corresponding calling rules when the target OpenAPI method adopts the Soap protocol, which is the specific implementation manner of step 1032.

In the OpenAPI calling method of the embodiment, the OpenAPI calling device directly acquires the calling rule corresponding to the Soap protocol when the target OpenAPI method adopts the Soap protocol, and automatically completes the calling of the target OpenAPI method according to the calling rule, and the user is no longer required to learn the Soap. The communication mechanism of the protocol improves the efficiency of calling the OpenAPI method.

FIG. 7 is a flowchart of a calling method when the target OpenAPI method adopts the Ajax protocol according to an embodiment of the present invention. As shown in FIG. 7, the method in this embodiment includes:

Step 701: The OpenAPI calling device acquires a target OpenAPI method according to a call request of the user. Step 702: The OpenAPI calling device provides a parameter list of the target OpenAPI method to the user. Step 703: The user inputs parameter information required by the target OpenAPI method according to the parameter list, and sends the parameter information to the OpenAPI calling device.

The foregoing step 701-step 703 is described in detail in step 501 - step 503, and details are not described herein again. Step 704: The OpenAPI calling device receives the parameter information, and obtains the first function code stored locally, and then acquires the second function code from the OpenAPI server according to the first function code, and performs parameter information on the first function code and the second function code. Processing, generating a third-party call request.

Wherein, since the OpenAPI method written by using the Ajax protocol needs to write different function codes to be called when calling, the first function code corresponding to each OpenAPI method is generated and stored in advance in the embodiment. In addition, calling the OpenAPI method implemented by the Ajax protocol also needs to download another part of the function code to the OpenAPI server. In this embodiment, when the first function code is obtained, the OpenAPI calling device is directly triggered to the OpenAPI server to obtain another part of the function code. , that is, the second function code (such as the required javascript code), and then combine the two parts of the function code to process the parameter information to generate a third-party call request.

Step 705: The OpenAPI calling device sends a third-party call request to the OpenAPI server to invoke the target OpenAPI method.

Specifically, the OpenAPI calling device generates and sends a third-party call request to the OpenAPI server by running the above function code.

Step 706: The OpenAPI calling device receives the call result returned by the OpenAPI server, and formats the call result by using a preset data format, and then sends the result to the user.

In the OpenAPI calling method of the embodiment, when the target OpenAPI method adopts the Ajax protocol, the OpenAPI calling device directly acquires the calling rule corresponding to the Ajax protocol, and automatically completes the calling of the target OpenAPI method according to the calling rule, and the user is no longer required to learn Ajax. The communication mechanism of the protocol improves the efficiency of calling the OpenAPI method.

In summary, the embodiments of the present invention automatically set the calling rule under each communication protocol and input the calling request by providing a unified calling interface to the user, which is automatically adopted by the OpenAPI calling device. The corresponding calling rule completes the call to each OpenAPI method, so that the user completes the call to various OpenAPI methods by using the same calling process, and does not need to learn various communication protocols, thereby improving the efficiency of calling the OpenAPI method and improving the user. Quality of service.

FIG. 8 is a schematic structural diagram of an OpenAPI calling device according to an embodiment of the present invention. As shown in FIG. 8, the calling device of this embodiment includes: a method obtaining unit 81, a parameter obtaining unit 82, and a calling unit 83.

The method obtaining unit 81 is configured to obtain a target OpenAPI method corresponding to the calling request of the user, and the parameter obtaining unit 82 is connected to the method acquiring unit 81, and configured to provide the user with a parameter list corresponding to the target OpenAPI method, to obtain The parameter information of the target OpenAPI method; the calling unit 83 is connected to the parameter obtaining unit 82, and is configured to invoke the target OpenAPI method according to the parameter information and the calling rule adapted to the target OpenAPI method.

The OpenAPI invoking device of this embodiment can be used to execute the process of the embodiment shown in FIG. 1. The working principle is not described here. For details, refer to the description of the method embodiment.

After obtaining the parameter information corresponding to the target OpenAPI method and the target OpenAPI method, the OpenAPI calling device in this embodiment invokes the target OpenAPI method by using a calling rule adapted to the target OpenAPI method, and implements unified for the user. The calling process implements calls to different OpenAPIs, which simplifies the calling process and improves the efficiency of calling OpenAPI.

FIG. 9 is a schematic structural diagram of an OpenAPI calling device according to another embodiment of the present invention. The embodiment is implemented based on the embodiment shown in FIG. 8. As shown in FIG. 9, an implementation structure of the method obtaining unit 81 of the embodiment includes: a first receiving subunit 811, a first API acquiring subunit 812, and a first A subunit 813 and a first method acquisition subunit 814 are provided.

Specifically, the first receiving subunit 811 is configured to receive a first call request sent by the user, where the first API obtaining subunit 812 is connected to the first receiving subunit 811, and configured to provide the OpenAPI list to the user according to the first calling request. In order to enable the user to select the target OpenAPI, the OpenAPI list includes information of a plurality of OpenAPIs; the first providing subunit 813 is connected to the first API obtaining subunit 812, configured to obtain a method list corresponding to the target OpenAPI, and provide the method list Give the user a choice for the user, The method list includes information of a plurality of OpenAPI methods. The first method obtaining subunit 814 is connected to the first providing subunit 813 for obtaining a target OpenAPI method according to a selection result of the user.

As shown in FIG. 9, another implementation structure of the method obtaining unit 81 includes: a second receiving subunit 815, a second API obtaining subunit 816, a second providing subunit 817, and a second method obtaining subunit 818.

Specifically, the second receiving subunit 815 is configured to receive a second calling request sent by the user, where the second calling request includes an OpenAPI keyword, and the second API obtaining subunit 816 is connected to the second receiving subunit 815, where The OpenAPI list is queried according to the OpenAPI keyword, and the target OpenAPI corresponding to the OpenAPI keyword is obtained. The OpenAPI list includes information of multiple OpenAPIs. The second providing subunit 817 is connected to the second API obtaining subunit 816 for obtaining the target OpenAPI. Corresponding method list, and providing the method list to the user for selection by the user, the method list includes information of multiple OpenAPI methods; the second method obtaining subunit 818 is connected with the second providing subunit 817 for Select the result and get the target OpenAPI method.

Further, as shown in FIG. 9, another implementation structure of the method obtaining unit 81 includes: a parameter obtaining subunit 819, a method set obtaining subunit 820, and a third method acquiring subunit 821.

Specifically, the parameter obtaining subunit 819 is configured to obtain an OpenAPI function parameter corresponding to the calling request, and the method set obtaining subunit 820 is connected to the parameter obtaining subunit 819, and configured to obtain an OpenAPI method set according to the OpenAPI function parameter, the OpenAPI The method set includes a plurality of OpenAPI methods corresponding to the OpenAPI function parameters; the third method obtaining subunit 821 is connected to the method set obtaining subunit 820, and is configured to collect the Qos attribute value of each OpenAPI method according to the OpenAPI method, and obtain the target OpenAPI method. .

An implementation structure of the parameter obtaining subunit 819 includes: a first receiving module and a first acquiring module. Specifically, the first receiving module is configured to receive a function call request sent by the user, where the function call request includes an OpenAPI function parameter; the first acquiring module is connected to the first receiving module, configured to parse the function call request, and obtain the OpenAPI function parameter. .

Yet another implementation structure of the parameter acquisition subunit 819 includes: a second receiving module and a second obtaining module. Specifically, the second receiving module is configured to receive an application call request sent by the user, where the application invokes The request includes the application description information. The second obtaining module is connected to the second receiving module, and is configured to perform function parsing processing on the application description information to obtain an OpenAPI function parameter.

The foregoing function sub-units or modules may be used to execute the processes of the foregoing embodiment shown in FIG. 2A to FIG. 2D, and the working principle thereof is not described again. For details, refer to the description of the method embodiments. The OpenAPI calling device specifically allows the user to input various calling requests through the above function sub-units or modules, thereby providing a more convenient calling interface for the user, further improving the efficiency of calling the OpenAPI method and improving the quality of service to the user.

Further, as shown in FIG. 9, the calling unit 83 of the present embodiment includes a rule acquisition subunit 831, a generation subunit 832, and a calling subunit 833.

The rule obtaining sub-unit 831 is configured to obtain a calling rule that is adapted to the target OpenAPI method according to the protocol type adopted by the target OpenAPI method, and generate a sub-unit 832, which is connected to the rule obtaining sub-unit 831, according to the calling rule, The parameter information is processed to generate a third-party call request; the calling sub-unit 833 is connected to the generating sub-unit 832 for sending a third-party calling request to the OpenAPI server to invoke the target OpenAPI method.

Specifically, when the target OpenAPI method is written by using the Rest protocol, the generating subunit 832 is specifically configured to receive the calling key Key value sent by the user, and query the OpenAPI list according to the target OpenAPI method to obtain the calling address; and the parameter information and the calling key. The value is encrypted to generate a third-party call request.

When the target OpenAPI method is written by the Soap protocol, the generating sub-unit 832 is specifically configured to query the OpenAPI list, obtain the WSDL2 Java toolkit of the Soa protocol, and process the parameter information and the target OpenAPI method by using the WSDL2 Java toolkit to generate a third-party calling request. .

When the target OpenAPI method is written by using the Ajax protocol, the generating subunit 832 is specifically configured to obtain a locally stored first function code corresponding to the target OpenAPI method; and acquiring the second function code from the API database according to the first function code; The function code and the second function code process the parameter information to generate a third-party call request.

Each of the above functional subunits can be used to execute the process of the embodiment shown in FIG. 3 or FIG. 5 to FIG. The working principle is not repeated here, as described in the section on method embodiments.

Further, the OpenAPI calling device of this embodiment further includes: a setting unit 84 and a receiving processing unit 85.

Specifically, the setting unit 84 is configured to set a data format of the returned result. The receiving processing unit 85 is connected to the setting unit 84, and is configured to receive a call result returned by the OpenAPI server, and format the call result according to the data format, and provide the processed call result to the user.

In summary, after obtaining the parameter information corresponding to the target OpenAPI method and the target OpenAPI method, the OpenAPI calling device in this embodiment invokes the target OpenAPI method by using a calling rule adapted to the target OpenAPI method, and The implementation of the call process to achieve different calls to the OpenAPI, simplifying the calling process and improving the efficiency of calling OpenAPI.

A person skilled in the art can understand that all or part of the steps of implementing the above method embodiments may be completed by using hardware related to program instructions, and the foregoing program may be stored in a computer readable storage medium, and the program is executed when executed. The foregoing steps include the steps of the foregoing method embodiments; and the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

It should be noted that the above embodiments are only for explaining the technical solutions of the present invention, and are not intended to be limiting; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those skilled in the art that: The technical solutions described in the foregoing embodiments are modified, or some of the technical features are equivalently replaced. The modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

Rights request

An open application programming interface OpenAPI calling method, comprising: obtaining a target OpenAPI method corresponding to a user's calling request;

Providing the user with a parameter list corresponding to the target OpenAPI method to obtain parameter information of the target OpenAPI method;

2. The OpenAPI calling method according to claim 1, wherein the obtaining a target OpenAPI method corresponding to a user's calling request comprises:

Receiving a first call request sent by the user;

Providing the OpenAPI list to the user according to the first call request, so that the user selects a target OpenAPI, where the OpenAPI list includes information of multiple OpenAPIs;

Obtaining a method list corresponding to the target OpenAPI, and providing the method list to the user for selection by the user, where the method list includes information of multiple OpenAPI methods;

Obtaining the target OpenAPI method according to the selection result of the user.

The OpenAPI calling method according to claim 1, wherein the obtaining the target OpenAPI method corresponding to the user's calling request comprises:

Receiving a second call request sent by the user, where the second call request includes an OpenAPI keyword;

Querying the OpenAPI list according to the OpenAPI keyword, and acquiring a target OpenAPI corresponding to the OpenAPI keyword, where the OpenAPI list includes information of multiple OpenAPIs;

The OpenAPI calling method according to claim 1, wherein the obtaining the target OpenAPI method corresponding to the user's calling request comprises: Obtaining an OpenAPI function parameter corresponding to the call request;

Obtaining an OpenAPI method set according to the OpenAPI function parameter, where the OpenAPI method set includes multiple OpenAPI methods corresponding to the OpenAPI function parameter;

The target OpenAPI method is obtained by concentrating the quality of service Qos attribute value of each of the OpenAPI methods according to the OpenAPI method.

The OpenAPI calling method according to claim 4, wherein the obtaining the OpenAPI function parameters corresponding to the calling request includes:

Receiving a function call request sent by the user, where the function call request includes an OpenAPI function parsing the function call request, and acquiring the OpenAPI function parameter.

Receiving an application call request sent by the user, where the application call request includes application description information; performing function parsing processing on the application description information to obtain the OpenAPI function parameter.

The OpenAPI calling method according to any one of claims 1 to 6, wherein the calling the target OpenAPI method according to the parameter information and a calling rule adapted to the target OpenAPI method Includes:

Obtaining a calling rule adapted to the target OpenAPI method according to a protocol type adopted by the target OpenAPI method;

And processing, according to the calling rule, the parameter information to generate a third-party calling request; and sending the third-party calling request to the OpenAPI server to invoke the target OpenAPI method.

8. The OpenAPI calling method according to claim 7, wherein the target OpenAPI method uses a representational state transition Rest protocol;

And processing the parameter information according to the calling rule, and generating a third-party calling request includes: Receiving a call key Key value sent by the user, and querying the OpenAPI list according to the target OpenAPI method to obtain a call address; and performing encryption processing on the parameter information and the call key value to generate the third party call request.

The OpenAPI calling method according to claim 7, wherein the target OpenAPI method adopts a simple object access protocol Soa;

And processing the parameter information according to the calling rule to generate a third-party calling request, including:

Querying the OpenAPI list, obtaining the WSDL2Java toolkit of the Soap protocol; processing the parameter information and the target OpenAPI method using the WSDL2 Java toolkit to generate the third-party call request.

The OpenAPI calling method according to claim 7, wherein the target OpenAPI method adopts an Ajax protocol;

Obtaining a first stored function code corresponding to the target OpenAPI method locally; acquiring, according to the first function code, a second function code from the API database; by using the first function code and the second function code Processing the parameter information to generate the third party call request.

The method of calling the OpenAPI according to claim 7, wherein the sending the third party call request to the OpenAPI server to invoke the target OpenAPI method comprises:

Set the data format for the returned result.

The OpenAPI calling method according to claim 11, further comprising: receiving a call result returned by the OpenAPI server, and formatting the call result according to the data format, and processing the processed result The result of the call is provided to the user.

13. An open application programming interface OpenAPI calling device, comprising: a method obtaining unit, configured to acquire a target OpenAPI method corresponding to a user's calling request; a parameter obtaining unit, configured to provide the user with a parameter list corresponding to the target OpenAPI method, to obtain parameter information of the target OpenAPI method;

The OpenAPI calling device according to claim 13, wherein the method obtaining unit comprises:

a first receiving subunit, configured to receive a first call request sent by the user;

a first API obtaining subunit, configured to provide the user according to the first call request

a list of OpenAPIs to enable the user to select a target OpenAPI, the OpenAPI list including information of a plurality of OpenAPIs;

a first providing subunit, configured to obtain a method list corresponding to the target OpenAPI, and provide the method list to the user for selection by the user, where the method list includes information of multiple OpenAPI methods;

The first method acquires a subunit, configured to obtain the target OpenAPI method according to the selection result of the user.

a second receiving subunit, configured to receive a second calling request sent by the user, where the second calling request includes an OpenAPI keyword;

a second API acquisition subunit, configured to query an OpenAPI list according to the OpenAPI keyword, and obtain a target OpenAPI corresponding to the OpenAPI keyword, where the OpenAPI list includes information of multiple OpenAPIs;

a second providing subunit, configured to obtain a method list corresponding to the target OpenAPI, and provide the method list to the user for selection by the user, where the method list includes information of multiple OpenAPI methods;

a second method of acquiring a subunit, configured to acquire the target according to the selection result of the user OpenAPI method.

a parameter obtaining subunit, configured to obtain an OpenAPI function parameter corresponding to the call request, and a method set obtaining subunit, configured to obtain an OpenAPI method set according to the OpenAPI function parameter, where the OpenAPI method set includes the OpenAPI function Multiple OpenAPI methods corresponding to the parameters;

The third method acquires a subunit, configured to obtain the target OpenAPI method according to the quality of service Qos attribute value of each of the OpenAPI methods according to the OpenAPI method.

The OpenAPI calling device according to claim 16, wherein the parameter obtaining subunit comprises:

a first receiving module, configured to receive a function call request sent by the user, where the function call request includes an OpenAPI function parameter;

The first obtaining module is configured to parse the function calling request, and obtain the OpenAPI function parameter.

a second receiving module, configured to receive an application call request sent by the user, where the application call request includes application description information;

a second obtaining module, configured to perform function parsing processing on the application description information, to obtain the

The OpenAPI calling device according to any one of claims 13 to 18, wherein the calling unit comprises:

a rule obtaining subunit, configured to acquire a calling rule adapted to the target OpenAPI method according to a protocol type adopted by the target OpenAPI method;

Generating a subunit, configured to process the parameter information according to the calling rule to generate a third party call request; The calling subunit is configured to send the third party invocation request to the OpenAPI server to invoke the target OpenAPI method.

The OpenAPI calling device according to claim 19, wherein the target OpenAPI method adopts a representational state transition Rest protocol;

The generating sub-unit is specifically configured to receive a call key value sent by the user, and query an OpenAPI list according to the target OpenAPI method to obtain a call address, and encrypt the parameter information and the call key value. , generating the third party call request.

The OpenAPI calling device according to claim 19, wherein the target OpenAPI method adopts a simple object access protocol Soap;

The generating subunit is specifically configured to query an OpenAPI list, and obtain the Soap protocol.

a WSDL2 Java toolkit; processing the parameter information and the target OpenAPI method using the WSDL2 Java toolkit to generate the third party call request.

The OpenAPI calling device according to claim 19, wherein the target OpenAPI method adopts an Ajax protocol; a first function code; and acquiring a second function code from the API database according to the first function code; The parameter information is processed by the first function code and the second function code to generate the third party call request.

The OpenAPI calling device according to claim 19, further comprising: a setting unit, configured to set a data format of the returned result.

The OpenAPI calling device according to claim 23, further comprising: a receiving processing unit, configured to receive a call result returned by the OpenAPI server, and format the calling result according to the data format Processing, providing the processed call result to the user.