CN114995791A

CN114995791A - API (application program interface) polymerization method and device, electronic equipment and storage medium

Info

Publication number: CN114995791A
Application number: CN202210621135.4A
Authority: CN
Inventors: 续延雨; 刘云峰
Original assignee: Shenzhen Zhuiyi Technology Co Ltd
Current assignee: Shenzhen Zhuiyi Technology Co Ltd
Priority date: 2022-06-01
Filing date: 2022-06-01
Publication date: 2022-09-02

Abstract

The application discloses an API polymerization method, an API polymerization device, electronic equipment and a storage medium, wherein the method comprises the following steps of; acquiring a user request; determining a target API aggregation mode corresponding to the user request according to the user request and an aggregation configuration file, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode; and calling the API corresponding to the target API polymerization mode according to the target API polymerization mode, and returning the data corresponding to the user request. The method comprises the steps of determining a target API aggregation mode by utilizing a user request and an aggregation configuration file, calling an API corresponding to the target API aggregation mode to respond to the user request so as to return data required by a user, and therefore, the user request which can be realized only by calling a plurality of APIs can be realized only by calling one or a few APIs aggregated by the target API aggregation mode, and the response rate is improved.

Description

API (application program interface) polymerization method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of data processing technologies, and in particular, to an API aggregation method and apparatus, an electronic device, and a storage medium.

Background

An Application Programming Interface (API), also called API, is a convention for linking different components of a software system. The primary purpose of an API is to provide applications and developers the ability to access a set of routines without accessing source code or understanding the details of the internal workings. Software that provides the functionality defined by an API is referred to as an implementation of this API.

For complex business logic, a large number of API requests need to be called, so that response is not timely enough, and efficiency of testing and development is low.

Disclosure of Invention

In view of the above, embodiments of the present application provide an API aggregation method, an API aggregation apparatus, an electronic device, and a storage medium to solve the above problem.

In a first aspect, an embodiment of the present application provides an API aggregation method, including: acquiring a user request; determining a target API aggregation mode corresponding to the user request according to the user request and an aggregation configuration file, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode; and calling the API corresponding to the target API polymerization mode according to the target API polymerization mode, and returning the data corresponding to the user request.

In a second aspect, an embodiment of the present application provides an API aggregation apparatus, including: the acquisition module is used for acquiring a user request; determining a target API aggregation mode, which is used for determining the target API aggregation mode corresponding to the user request according to the user request and an aggregation configuration file, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode; and the calling API module is used for calling the API corresponding to the target API polymerization mode according to the target API polymerization mode and returning the data corresponding to the user request.

In a third aspect, an embodiment of the present application provides an electronic device, including: a processor; a memory having computer readable instructions stored thereon which, when executed by the processor, implement the API aggregation method as above.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium having stored thereon computer-readable instructions, which, when executed by a processor, implement the API aggregation method as above.

According to the scheme, the target API aggregation mode is determined by utilizing the user request and the aggregation configuration file, the API corresponding to the target API aggregation mode is called to respond to the user request, and data needed by the user is returned, so that one user request which can be realized by calling a plurality of APIs can be realized by calling one or a few APIs aggregated by the target API aggregation mode adaptive to the user request, the response rate is improved, the target API aggregation mode is realized by aggregating the configuration file, the aggregation configuration file can be changed according to the specific requirements of the user, and the aggregation test and development efficiency is improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 illustrates a block diagram of an electronic device suitable for use in implementing embodiments of the present application.

Fig. 2 is a flowchart illustrating an API aggregation method according to an embodiment of the present application.

FIG. 3 shows a flowchart of one embodiment of step S220 in FIG. 2.

Fig. 4 shows a flowchart of an API aggregation method according to another embodiment of the present application.

Fig. 5 shows a flow diagram of a one-to-one dependent aggregation approach of the present application.

Fig. 6 shows a flowchart of an API aggregation method according to another embodiment of the present application.

Fig. 7 shows a flow diagram of a many-to-many dependent aggregation approach of the present application.

Fig. 8 shows a flowchart of an API aggregation method according to still another embodiment of the present application.

Fig. 9 shows a schematic flow diagram of the parallel input aggregation mode of the present application.

Fig. 10 shows a flowchart of an API aggregation method according to still another embodiment of the present application.

Fig. 11 shows a schematic flow diagram of the parallel merge polymerization approach of the present application.

Fig. 12 shows a flowchart of configuration file listening in an API aggregation method provided in an embodiment of the present application.

FIG. 13 illustrates an API gateway architecture diagram according to an embodiment of the present application.

Fig. 14 shows a timing diagram of an embodiment of the present application.

Fig. 15 shows a block diagram of an API aggregation apparatus provided in an embodiment of the present application.

Detailed Description

Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the application. One skilled in the relevant art will recognize, however, that the subject matter of the present application can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the application.

The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.

The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.

It should be noted that: reference herein to "a plurality" means two or more. "and/or" describe the association relationship of the associated objects, meaning that there may be three relationships, e.g., A and/or B may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

For services with a large number of services, high complexity and large scale, a gateway service unified management back-end service API needs to be introduced and forwarded according to a front-end request. If the API request logic is complex, the front end needs to sense the service logic and call a large number of API requests, which results in high front-end and back-end network overhead and high front-end development complexity.

Therefore, the inventor provides an API aggregation method, an API aggregation device, an electronic device, and a storage medium, which first determine a target API aggregation mode by using a user request and an aggregation configuration file, and then call an API corresponding to the target API aggregation mode to respond to the user request and return data required by a user, so that a user request that can be realized only by calling a plurality of APIs can be realized only by calling one or a few APIs aggregated by the target API aggregation mode, thereby improving a response rate.

Referring to fig. 1, fig. 1 shows a block diagram of an electronic device suitable for implementing an embodiment of the present application, where the electronic device shown in fig. 1 may include a terminal device or a server, and the terminal may be a smart phone, a gateway, a tablet computer, a notebook computer, a desktop computer, or the like. The server may be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, a middleware service, a domain name service, a security service, a CDN (Content Delivery Network), a big data and artificial intelligence platform.

In the electronic device shown in fig. 1, the memory 1005, which is a kind of storage medium, may include therein an operating system, a data storage module, a network communication module, a user interface module, and an electronic program. The network interface 1004 is mainly used for data communication with a network server; the user interface 1003 is mainly used for data interaction with a user; the communication bus 1002 is mainly used for communication interaction between the memory 1005, the network interface 1004, the user interface 1003 and the server; the processor 1001 and the memory 1005 in the electronic device according to the present invention may be disposed in the electronic device, and the electronic device calls the API aggregation apparatus stored in the memory 1005 through the processor 1001 and respectively executes the API aggregation method provided in the embodiment of the present application.

Processor 1001 may include one or more processing cores. The processor 1001 connects various parts within the entire electronic device using various interfaces and lines, and performs various functions of the electronic device and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 1005 and calling data stored in the memory 1005. Alternatively, the processor 1001 may be implemented in hardware using at least one of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 1001 may integrate one or a combination of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a modem, and the like. The CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for rendering and drawing display content; the modem is used to handle wireless communications. It is understood that the above modem may not be integrated into the processor 1001, but may be implemented by a communication chip.

The Memory 1005 may include a Random Access Memory (RAM) or a Read-Only Memory (Read-Only Memory). The memory 1005 may be used to store an instruction, a program, code, a set of codes, or a set of instructions. The memory 1005 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for implementing at least one function (such as a touch function, an alarm function, etc.), instructions for implementing various method embodiments described below, and the like. The storage data area may also store data created by the electronic device in use (such as disguised response commands, acquired process status), and the like.

Those skilled in the art will appreciate that the configuration shown in fig. 1 does not constitute a limitation of the electronic device and may include more or fewer components than those shown, or some components may be combined, or a different arrangement of components.

Fig. 2 is a flow diagram illustrating an API aggregation method that may be performed by a processing-capable electronic device (e.g., which may be a gateway), according to one embodiment of the application. Referring to fig. 2, the method at least includes steps S210 to S230, which are described in detail as follows:

step S210, a user request is acquired.

The method comprises the steps of obtaining a user request sent by a front end, wherein the user request can carry service codes or information of user indication service scenes such as scene requirements and the like.

Step S220, according to the user request and the aggregation configuration file, determining a target API aggregation mode corresponding to the user request, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode.

The user request corresponds to a service scenario, which may be a service scenario explicitly indicated in the user request or a service scenario inferred by the user request.

A configuration file is a computer file that performs different configurations for different objects. The profiles include a local user profile, a roaming user profile, a forced user profile, and a temporary profile.

The aggregation configuration file in the embodiment of the application refers to a configuration file which is written with codes to form a plurality of specific API aggregation modes and service scenes corresponding to the API aggregation modes. The aggregation configuration file comprises a corresponding relation between the service scene and the API aggregation mode, and developers can set and update the aggregation configuration file according to experience data and by combining with the specific service scene. It can be understood that, in order to improve efficiency, the configuration of the target API aggregation manner may be performed according to different service scenarios and specific requirements.

When the user request conforms to one service scene in the aggregation configuration file, the API required to be called by the user request is aggregated according to the API aggregation mode corresponding to the service scene. The aggregation configuration file may be a workflow configuration file, and the type of the configuration file is not particularly limited.

For example, according to the user request and the aggregation configuration file, a specific determination method for determining the target API aggregation manner corresponding to the user request may include the flow shown in fig. 3:

step S222, determining a service scenario corresponding to the user request according to the user request.

In some embodiments, the user request may carry a service scenario code or an identifier, and the corresponding service scenario may be determined according to the code or the identifier.

In other embodiments, the determination of the business scenario may also be performed by a pre-training model, which may be trained by a large-scale user request. And inputting the acquired user request into the pre-training model to obtain a corresponding service scene.

Step S224, obtaining a target API aggregation mode corresponding to the user request according to the determined service scenario and the correspondence between the service scenario in the aggregation configuration file and the API aggregation mode.

Because the aggregation configuration file has the corresponding relation between the service scene and the API aggregation mode, after the service scene corresponding to the user request is determined according to the user request, the API aggregation mode corresponding to the service scene can be obtained in the aggregation configuration file and is used as the target API aggregation mode corresponding to the user request.

Step S230, according to the target API aggregation manner, calling an API corresponding to the target API aggregation manner, and returning data corresponding to the user request.

Each target API aggregation mode may involve multiple APIs, and when the target API aggregation mode is called, the multiple APIs in the target API aggregation mode are called to operate. The aggregation mode can be a dependent aggregation mode or a parallel aggregation mode, so that the data required by the user request can be obtained.

The dependency aggregation mode means that a plurality of APIs required by a user request correspond to respective functions, data processed by one or more APIs is performed depending on output of the previous one or more APIs, and the parallel aggregation mode means that a dependency relationship does not exist among the plurality of APIs required by the user request.

For example, the user request is "month bill of the year", the corresponding service scenario is "month bill", and if each month bill corresponds to one API, the 12 APIs are aggregated in the aggregation mode corresponding to the "month bill" of the service occasion, so that the data of the month bill of the year of the client is returned. Such a polymerization system is a parallel polymerization system.

If the user request is that the user request is 'the first month and first week bills in the current year', each month bill corresponds to one API, each month and middle week bill corresponds to one API, at the moment, polymerization is carried out by adopting a polymerization-dependent mode through the 'week bills' in the service occasion, the API corresponding to the first month bill is called from the year bill API, then the first week bill API is called from the first month bill, and therefore the first month and first week bill data of the client are returned.

In the application, a target API aggregation mode is determined by using a user request and an aggregation configuration file, and then an API corresponding to the target API aggregation mode is called to respond to the user request so as to return data required by a user, so that one user request which can be realized by calling a plurality of APIs can be realized by only calling one or a few APIs aggregated by the target API aggregation mode, and thus, the response speed is improved.

Fig. 4 is a flowchart illustrating an API aggregation method according to another embodiment of the present application, which may be performed by an electronic device with processing capability, and is not limited in this respect. Referring to fig. 4, the method includes:

step S310, a user request is obtained.

Step S320, determining a target API aggregation mode corresponding to the user request according to the user request and an aggregation configuration file, where the aggregation configuration file includes a correspondence between a service scenario and the API aggregation mode.

The specific implementation of steps S310 to S320 can refer to corresponding steps S210 to S220 in the foregoing embodiment, and details are not repeated here.

And step S330, when the target API polymerization mode is determined to be one-to-one dependency polymerization in the dependency polymerization modes, sequentially calling a plurality of APIs according to the target API polymerization mode, wherein the output of the former API is used as the input of the latter API.

And taking the input of the former API as the output of the latter API, and carrying out layer-by-layer processing on the user request to obtain a final API output result so as to obtain data corresponding to the user request.

For example, in a speech recommendation scenario, API1 is an upload corpus, API2 is a preprocess for a corpus, API3 implements speech mining, the upload of the corpus is performed first, the uploaded corpus is processed, and the processed corpus is subjected to data mining, so as to obtain speech recommendation data mined by API3 and required by a user.

Step S340, returning the data output by the last API as the data corresponding to the user request.

In this embodiment, a plurality of APIs are sequentially called, and an aggregation mode in which an output of a previous API is used as an input of a subsequent API is a one-to-one dependent aggregation mode. Referring to fig. 5, fig. 5 shows a flow diagram of a one-to-one dependent aggregation manner of the present application, and an aggregation configuration file corresponding to the one-to-one dependent aggregation manner may be implemented by:

as can be seen from the above, call API1{ input: in ═ firstInput } indicates that API1 is used as an input of file firstInput, call API2{ input: in ═ API1.out } indicates that the input of API2 is obtained from the output of API1, call API3{ input: in ═ API2.out } indicates that the input of API3 is the output of API2, and the data returned to the user finally is the output of API 3.

Fig. 6 is a flowchart illustrating an API aggregation method according to another embodiment of the present application, which may be executed by an electronic device with processing capability, and is not limited in this respect. Referring to fig. 6, the method includes:

step S410, a user request is obtained.

Step S420, according to the user request and the aggregation configuration file, determining a target API aggregation mode corresponding to the user request, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode.

The specific implementation of steps S410 to S420 can refer to corresponding steps S210 to S220 in the foregoing embodiments, and details are not repeated here.

Step S430, when the target API aggregation mode is determined to be many-to-many dependency aggregation in dependency aggregation modes, sequentially calling a first API, a plurality of second APIs and a third API according to the target API aggregation mode, taking the output of the first API as the input of the second APIs respectively, and taking the output of the second APIs as the input of the third API.

The API (application programming interface) 1 which is necessary for the user request is analyzed according to the user request, the API1 decomposes the user request to obtain different request requirements, and different APIs are required to process according to different request requirements, so that the output of the API1 is simultaneously used as the input of a plurality of different APIs, after the processing of the plurality of APIs, data processed by some APIs are permanently stored, and data of some APIs are used as the input of the next API, and then the user request is deeply analyzed until data corresponding to the user request is obtained.

For example, in the label labeling scenario, after the API1 preprocessing flow is completed, API2 pre-labeling, API3 deactivation data processing and API4 clustering are performed simultaneously, and there is no dependency among the flows, wherein the API3 deactivation data is not output after being processed, and finally the API4 labeling model results in processing the output of the API2 pre-labeling and API3 deactivation data processing.

And step S440, returning the data output by the last API as the data corresponding to the user request.

In this embodiment, an API aggregation scheme in which a first API, a plurality of second APIs, and a third API are sequentially called and outputs of the first API are input to the plurality of second APIs is a many-to-many dependent aggregation scheme. Referring to fig. 7, fig. 7 shows a flow diagram of a many-to-many dependent aggregation manner of the present application, and an aggregation configuration file of the many-to-many dependent aggregation manner may be the following code:

the call API1{ input: in ═ firtinput } represents the API1 as the input of the file firstInput, the call API2{ input: in ═ API1.out }, the call API3{ input: in ═ API1.out }, the call API4{ input: in ═ API1.out }, and the call API5{ input: in ═ API1.out } represent the APIs 2, API3, API4, and API5 as the inputs from the output of the API1, the call API6{ input: in1 ═ API2.out, in2 ═ API4.out } represents the inputs of the API6 as the outputs of the API2 and API4, the final returned user data is the output of the API3, the API3 and the API5 are stored as the inputs, or the other inputs are not limited to the inputs.

Fig. 8 is a flowchart illustrating an API aggregation method according to a fourth embodiment of the present application, which may be executed by an electronic device with processing capability, and is not limited in detail herein. Referring to fig. 8, the method includes:

step S510, a user request is obtained.

Step S520, according to the user request and the aggregation configuration file, determining a target API aggregation mode corresponding to the user request, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode.

The specific implementation manner of steps S510 to S5420 can refer to corresponding steps S210 to S220 in the foregoing embodiment, and details are not described here.

Step S530, when the target API polymerization mode is determined to be the parallel input polymerization in the parallel polymerization mode, according to the target API polymerization mode, a plurality of first APIs and a second API are called in sequence, and the output of the first APIs is used as the input of the second API.

And analyzing the user request to obtain a plurality of different APIs for processing the user request, taking the output of the plurality of first APIs as the input of a second API, and returning the output processed by the second API as data corresponding to the user request.

For example, e-commerce document generation, API1 is selling point generation, API2 is selling point classification, there is no dependency between the two APIs, API3 is document generation, and API3 can be executed by parallel aggregation if output results of API1 and API2 are required.

And step S540, returning the data output by the last API as the data corresponding to the user request.

In this embodiment, the API aggregation mode in which a plurality of first APIs and a plurality of second APIs are sequentially called and outputs of the plurality of first APIs are input to the second API is a parallel input aggregation mode. Referring to fig. 9 and fig. 9, a flow diagram of the parallel input aggregation mode of the present application is shown in fig. 9, and an aggregation configuration file of the parallel input aggregation mode may be the following codes:

wherein scatter in first input means that a plurality of parallel and independent APIs are obtained by scatter key scatter of scatter gather function, then the output of the plurality of parallel and independent APIs are gathered by using gather key, the output of the scatter gather function is used as the input of API4, and the final output result is the output of API4.

Fig. 10 is a flowchart illustrating an API aggregation method according to a fifth embodiment of the present application, which may be performed by an electronic device with processing capability, and is not limited in particular herein. Referring to fig. 10, the method includes:

step S610, a user request is acquired.

Step S620, according to the user request and the aggregation configuration file, determining a target API aggregation mode corresponding to the user request, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode.

The specific implementation manner of steps S610 to S620 may refer to corresponding steps S210 to S220 in the foregoing embodiment, and details are not repeated here.

Step S630, when the target API polymerization mode is determined to be parallel combination polymerization in the parallel polymerization mode, sequentially calling a plurality of first APIs according to the target API polymerization mode, and simultaneously outputting the output of the plurality of first APIs.

And acquiring a plurality of APIs required by the user request, and simultaneously outputting data after the data are processed by the plurality of APIs so as to obtain the data corresponding to the user request.

For example, in the similar question mining scenario, the API1 obtains the clustering result of the similar question, and the AP2 obtains the recommendation result of the similar question, so that the two APIs can be aggregated in an API parallel aggregation manner to return the clustering result and the recommendation result of the similar question.

Step S640 returns the output of the plurality of first APIs as data corresponding to the user request.

In this embodiment, the API aggregation manner for sequentially calling the plurality of first APIs and simultaneously outputting the outputs of the plurality of first APIs may be a parallel merge aggregation manner. Referring to fig. 11 and fig. 11 show a schematic flow diagram of a parallel merge aggregation manner according to the present application, and an aggregation configuration file of the parallel merge aggregation manner may be the following code:

the input of the call API1{ input: in ═ first input }, the call API2{ input: in ═ first input } and the call API3{ input: in ═ first input } represent that the inputs of the API1, the API2 and the API3 come from the same file, the outputs of the API1, the API2 and the API3 are merged by a merge function, and the merged result is output.

Referring to fig. 12, in the present application, the method may include:

step S710, reading and analyzing the aggregation configuration file.

Step S720, when the update information of the aggregation configuration file is acquired, updating the corresponding relation between the service scene and the API aggregation mode according to the update information.

When the aggregation configuration file is read and analyzed by using the monitoring tool until the aggregation configuration file is read to the cloud end, the local aggregation configuration file is automatically updated, and the real-time updating of the local aggregation configuration file is realized.

The listening tool may be an inotify listening tool, which is a Linux feature that monitors file system operations such as read, write, and create. Inotify reaction is sensitive, and the usage is very simple.

In a specific implementation process, the foregoing solution of the present application may be implemented by an API aggregation module. Referring to fig. 13, fig. 13 is a diagram illustrating an API gateway architecture of the present application with API aggregation functionality interposed between a pre-filter module and route forwarding. Referring to fig. 14, fig. 14 shows a timing diagram of an embodiment of the application, where an API aggregation function is between a pre-filter module and route forwarding, a current end receives a user request, and a front end parses an API route and an API request included in the user request. And forwarding the API request to an API gateway, judging what API aggregation type the API corresponds to by the API gateway, and forwarding the API request to a back-end server by the API gateway. And after the processing of the back-end server, the API request is forwarded to an API gateway post-filter, the API post-filter analyzes the API request into a response state and serialized data, and transmits the analyzed response state and serialized data to an API aggregation module. And the API aggregation module carries out aggregation and deserialization operations on the received data and returns an aggregation result to the API post-filter, and the API post-filter responds to the user request according to whether the aggregation result returned by the API aggregation module is consistent with the result judged by the API gateway or not. If not, a series of operations from the forwarding operation of the API gateway to the judging operation of the post filter are carried out again until the response is successful or the threshold value of the re-operation is reached.

In summary, the API aggregation method provided in the embodiment of the present application may determine the target API aggregation manner by using the user request and the aggregation configuration file, and then call the API corresponding to the target API aggregation manner to respond to the user request so as to return the data required by the user, so that one user request that can be implemented by calling multiple APIs can be implemented by only calling one or a few APIs aggregated by the target API aggregation manner, thereby improving the response rate.

Fig. 15 is a block diagram of an API aggregation apparatus according to an embodiment of the present application, and as shown in fig. 14, the API aggregation apparatus 80 includes:

an acquisition module 810; the method comprises the steps of obtaining historical service data in a first preset time length, wherein the first preset time length comprises a plurality of unit time lengths;

a target API aggregation mode determining module 820, configured to decompose the historical service data to obtain trend data and periodic data of the historical service data;

the calling API module 830 is used for acquiring working time trend data and non-working time trend data within the first preset time length based on the change rate of the trend data within each unit time length;

in some embodiments of the present application, the module 820 for determining a target API aggregation manner includes a module for determining a service scenario, configured to determine, according to the user request, a service scenario corresponding to the user request; and the target API aggregation mode obtaining module is used for obtaining the target API aggregation mode corresponding to the user request according to the determined service scene and the corresponding relation between the service scene and the API aggregation mode in the aggregation configuration file.

In some embodiments of the present application, the API aggregation mode includes a dependent aggregation mode and/or a parallel aggregation mode, and the pre-call API module 830 includes a one-to-one dependent aggregation module for sequentially calling a plurality of APIs, where an output of a previous API serves as an input of a next API.

In some embodiments of the present application, the pre-call API module 830 further includes a call many-to-many dependency aggregation module, configured to call the first API, the multiple second APIs, and the third API in sequence, and take the output of the first API as the input of the multiple second APIs, and take the output of the multiple second APIs as the input of the third API.

In some embodiments of the present application, the pre-call API module 830 further includes a call parallel input aggregation module, configured to sequentially call a plurality of first APIs and a second API, and use outputs of the plurality of first APIs as inputs of the second API.

In some embodiments of the present application, the pre-call API module 830 further includes a call parallel merge aggregation module, configured to sequentially call a plurality of first APIs and output outputs of the plurality of first APIs.

In some embodiments of the present application, the API aggregation apparatus 80 further includes a reading and parsing module, configured to read and parse the aggregation configuration file; and the updating module is used for updating the corresponding relation between the service scene and the API aggregation mode according to the updating information when the updating information of the aggregation configuration file is acquired.

It should be noted that, in this embodiment, each module in the API aggregation device corresponds to each step in the API aggregation method in the foregoing embodiment one to one, and therefore, the specific implementation of this embodiment may refer to the implementation of the API aggregation method, which is not described herein again.

It should be understood that the above is only an example, and the technical solution of the present application is not limited in any way, and those skilled in the art can set the solution based on the needs in practical application, and the solution is not limited herein.

The present application further provides a computer readable storage medium having stored thereon computer readable instructions which, when executed by a processor, implement the method in any of the method embodiments described above.

The computer-readable storage medium may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read only memory), an EPROM, a hard disk, or a ROM. Alternatively, the computer-readable storage medium comprises a non-volatile computer-readable medium. The computer readable storage medium has storage space for computer readable instructions for performing any of the method steps of the above-described method. The computer readable instructions may be read from or written to one or more computer program products. The computer readable instructions may be compressed, for example, in a suitable form.

According to an aspect of an embodiment of the present application, there is provided a computer program product or a computer program comprising computer instructions stored in a computer readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions to cause the computer device to perform the method of any of the above embodiments.

It should be noted that although in the above detailed description several modules or units of the device for action execution are mentioned, such a division is not mandatory. Indeed, the features and functionality of two or more modules or units described above may be embodied in one module or unit, according to embodiments of the application. Conversely, the features and functions of one module or unit described above may be further divided into embodiments by a plurality of modules or units.

Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which can be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present application.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. An API polymerization method, comprising:

acquiring a user request;

determining a target API aggregation mode corresponding to the user request according to the user request and an aggregation configuration file, wherein the aggregation configuration file comprises a corresponding relation between a service scene and the API aggregation mode;

and calling the API corresponding to the target API polymerization mode according to the target API polymerization mode, and returning the data corresponding to the user request.

2. The method according to claim 1, wherein the determining a target API aggregation mode corresponding to the user request according to the user request and an aggregation profile comprises:

determining a service scene corresponding to the user request according to the user request;

and acquiring a target API aggregation mode corresponding to the user request according to the determined service scene and the corresponding relation between the service scene and the API aggregation mode in the aggregation configuration file.

3. The method of claim 1, wherein the API aggregation mode comprises a dependent aggregation mode and/or a parallel aggregation mode.

4. The method of claim 3, wherein the dependency aggregation mode comprises a one-to-one dependency aggregation, and wherein invoking the API corresponding to the target API aggregation mode comprises:

and sequentially calling a plurality of APIs, wherein the output of the former API is used as the input of the latter API.

5. The method of claim 3, wherein the dependency aggregation mode comprises a many-to-many dependency aggregation comprising:

the method comprises the steps of calling a first API, a plurality of second APIs and a third API in sequence, taking the output of the first API as the input of the second APIs, and taking the output of the second APIs as the input of the third API.

6. The method of claim 3, wherein the parallel aggregation mode comprises a parallel input aggregation comprising:

and sequentially calling a plurality of first APIs and a plurality of second APIs, and taking the output of the first APIs as the input of the second API.

7. The method of claim 3, wherein the parallel aggregation mode comprises a parallel merge aggregation, and wherein the parallel merge aggregation comprises:

and sequentially calling a plurality of first APIs, and simultaneously outputting the output of the first APIs.

8. The method according to any one of claims 1-7, further comprising:

reading and analyzing the aggregation configuration file;

and when the updating information of the aggregation configuration file is acquired, updating the corresponding relation between the service scene and the API aggregation mode according to the updating information.

9. An API aggregation device, comprising:

the acquisition module is used for acquiring a user request;

a target API aggregation mode determining module, configured to determine, according to the user request and an aggregation configuration file, a target API aggregation mode corresponding to the user request, where the aggregation configuration file includes a correspondence between a service scenario and the API aggregation mode;

and the calling API module is used for calling the API corresponding to the target API polymerization mode according to the target API polymerization mode and returning the data corresponding to the user request.

10. An electronic device, comprising:

a processor;

a memory having computer-readable instructions stored thereon which, when executed by the processor, implement the method of any one of claims 1-8.

11. A computer-readable storage medium, having stored thereon program code that can be invoked by a processor to perform the method according to any one of claims 1-8.