CN111930534A - Data calling method and device and electronic equipment - Google Patents

Abstract

According to the data calling method, the data calling device and the electronic equipment, after the generated target request is detected, the target interface parameters can be directly obtained from the preset interface parameter list according to the target request name of the target request, the first request data can be generated based on the target interface parameters and the content of the target request, and the first request data can be responded by the server of the server side and receives the return value. That is, it can be understood that: the client does not limit the specific interface parameters, but acquires the corresponding interface parameters according to the request name of the request. That is, when the client sends any request service, the client does not need to suspend its own service, thereby simplifying the RPC calling process. That is, it can be understood that in this way, the client does not need to generate an RPC call code during the call process of adding RPC.

Description

Data calling method and device and electronic equipment

Technical Field

The present disclosure relates to the field of internet technologies, and in particular, to a data calling method and apparatus, and an electronic device.

Background

A Remote Procedure Call Protocol (RPC) refers to a process of performing communication between two processes through a network, and in a RPC calling process, a client needs to pack request data (request data) into a byte stream according to a certain format and send the byte stream to a server; after receiving the data streams, the server acquires a request from the byte stream, acquires a return value (response) required to be returned to the client according to the content of the request, and packs the return value into the byte stream according to a certain format to be returned to the client; this completes one RPC call.

These data include the contents of the Interface, which are usually specified by an Interface Definition Language (IDL). That is, to complete the call, the two servers (server a and server B) need to generate corresponding codes according to the IDL file, so as to implement RPC call.

Disclosure of Invention

This disclosure is provided to introduce concepts in a simplified form that are further described below in the detailed description. This disclosure is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

The embodiment of the disclosure provides a data calling method, a data calling device and an electronic device, which enable request services generated by a client to be executed by setting a dynamically maintainable interface parameter list, that is, when the client needs to send a request, the client can obtain corresponding interface parameters from a preset interface parameter list according to a request name of the request.

In a first aspect, an embodiment of the present disclosure provides a data calling method, including: in response to detecting that a target request is generated, according to a target request name of the target request, acquiring a target interface parameter corresponding to the target request name from a preset interface parameter list, wherein the preset interface parameter list comprises: requesting the corresponding relation between the name and the interface parameter; generating first request data based on the target interface parameters and the target request, and sending the first request data to a server indicated by the target request, wherein the server can read the first request data; and receiving a return value, wherein the server generates the return value according to the received first request data.

In a second aspect, an embodiment of the present disclosure provides a data invoking device, including: an obtaining unit, configured to, in response to detecting that a target request is generated, obtain, according to a target request name of the target request, a target interface parameter corresponding to the target request name from a preset interface parameter list, where the preset interface parameter list includes: requesting the corresponding relation between the name and the interface parameter; a generating unit, configured to generate first request data based on the target interface parameter and the target request, and send the first request data to a server indicated by the target request, where the server is capable of reading the first request data; and a receiving unit, configured to receive a return value, where the server generates the return value according to the received first request data.

In a third aspect, an embodiment of the present disclosure provides an electronic device, including: one or more processors; a storage device, configured to store one or more programs, which when executed by the one or more processors, cause the one or more processors to implement the data call method according to the first aspect.

In a fourth aspect, the disclosed embodiments provide a computer readable medium, on which a computer program is stored, which when executed by a processor implements the steps of the data call method as described above in the first aspect.

According to the data calling method, the data calling device and the electronic equipment, after the generated target request is detected, the target interface parameters can be directly obtained from the preset interface parameter list according to the target request name of the target request, the first request data can be generated based on the target interface parameters and the content of the target request, and the first request data can be responded by the server of the server side and receives the return value. That is, it can be understood that: the client does not limit the specific interface parameters, but acquires the corresponding interface parameters according to the request name of the request. That is, when the client sends any request service, the client does not need to suspend its own service, thereby simplifying the RPC calling process. That is, it can be understood that in this way, the client does not need to generate an RPC call code during the call process of adding RPC.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numbers refer to the same or similar elements. It should be understood that the drawings are schematic and that elements and features are not necessarily drawn to scale.

FIG. 1 is a flow diagram for one embodiment of a data call method according to the present disclosure;

FIG. 2 is an interaction diagram for one embodiment of a data call method according to the present disclosure;

FIG. 3 is a schematic block diagram illustrating one embodiment of a data call device in accordance with the present disclosure;

FIG. 4 is an exemplary system architecture to which the data call method of one embodiment of the present disclosure may be applied;

fig. 5 is a schematic diagram of a basic structure of an electronic device provided according to an embodiment of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order, and/or performed in parallel. Moreover, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "include" and variations thereof as used herein are open-ended, i.e., "including but not limited to". The term "based on" is "based, at least in part, on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Relevant definitions for other terms will be given in the following description.

It should be noted that the terms "first", "second", and the like in the present disclosure are only used for distinguishing different devices, modules or units, and are not used for limiting the order or interdependence relationship of the functions performed by the devices, modules or units.

It is noted that references to "a", "an", and "the" modifications in this disclosure are intended to be illustrative rather than limiting, and that those skilled in the art will recognize that "one or more" may be used unless the context clearly dictates otherwise.

The names of messages or information exchanged between devices in the embodiments of the present disclosure are for illustrative purposes only, and are not intended to limit the scope of the messages or information.

Referring to FIG. 1, a flow diagram of one embodiment of a data call method according to the present disclosure is shown. The data call method may be applied to a server. It should be noted that, in an RPC calling process, there may be a server that initiates a request and a server that runs a corresponding program according to the request and returns a result. Therefore, for the sake of convenience of distinction, a server that initiates a request service may be referred to as a service initiator (or as a client), and a server that responds to a request service may be referred to as a service acceptor (or as a server). Here, the data call method may be applied to a service originator (client).

Step 101, in response to detecting that a target request is generated, according to a target request name of the target request, obtaining a target interface parameter corresponding to the target request name from a preset interface parameter list.

Here, the preset interface parameter list includes: and requesting the corresponding relation between the name and the interface parameter.

In some embodiments, the client may include: a database for storing interface parameters (IDL files), parsing interface parameters, for ease of illustration, to better understand the ideas provided by the present disclosure, Kael library can be used to characterize: the database is used for storing the interface parameters and the interface parameters; in other words, the database for storing and parsing the interface parameters may be named: kael library.

In some embodiments, a preset interface parameter list may be stored in the Kael library in advance, and in the preset parameter list, a correspondence between a request name and an interface parameter is recorded. Therefore, when the generated target request is detected, the corresponding target interface parameter can be known only according to the target request name of the target request, and the target interface parameter defines the sending format of the target request.

In some embodiments, it may also be understood that: the Kael library may maintain the interface parameters of all services, in other words, all services may submit the corresponding interface parameters to the Kael library for maintenance.

In some embodiments, the target request may be used to characterize: the client requests a request of a certain process of the server, in other words, it can also be understood that the client may generate a target request when the client needs to request (call) a certain interface of the server. That is, the target request may include: the method comprises the steps of requesting a name and requesting parameters, wherein the requesting parameters are parameters input when the server-side process is accessed, and the server-side runs a corresponding process based on the requesting parameters and returns an obtained result to a client.

And 102, generating first request data based on the target interface parameters and the target request, and sending the first request data to a server (server of a server) indicated by the target request, wherein the server (server of the server) can read the first request data.

In some embodiments, since the client and the server are two different servers, codes running on the two servers may be different, and therefore, in order to ensure that a target request sent by the client can be responded by the server, the client is required to convert the target request to be sent into a data type (data format) that the server can respond to.

In some embodiments, the target interface parameter may define a data format to be converted by the target request, and therefore, the target request may be parsed according to the target interface parameter to generate the first request data (parsing result). And further, the generated first request data can be responded by the server.

Step 103, receiving a return value.

Here, the server (server of the server) generates a return value based on the received first request data.

In some embodiments, since the first request data is sent according to a data format to which the server can respond, after the server receives the first request data, the server may execute a corresponding program according to the content (request parameter) in the first request data, and generate a corresponding return value. Accordingly, the received return value may be in the data format of the server, and therefore, the return value may also be converted into the data format that the client can respond to through the Kael library.

It can be seen that, by means ofsteps 101 to 103, when a request needs to be initiated for a certain interface, the request only needs to be sent to the Kael library, and the Kael library may determine corresponding interface parameters according to the request name of the request, where the interface parameters may define the data format of the request. Therefore, after the request content is read, the request data can be generated according to the data format defined by the interface parameters, and the request data is sent to the server. In this way, the client can find the corresponding interface parameter through the Kael library no matter which interface of the access server is indicated by the generated access request. That is, because the client includes the Kael library, all requests of the client can be sent through the Kael library, in other words, it can be understood that the Kael library provides a common interface for the client, and when the client needs to send a request, only the interface parameter corresponding to the common interface needs to be changed.

However, in the prior art, the client does not include a Kael library (or is referred to as not maintaining a Kael library), so that only part of the interface parameters can be recorded in the client, and when the client needs to call a new service or adds a new interface to an original service, the interface parameters need to be added, and the execution code is newly generated according to the interface parameters (that is, the code for converting the target request into the data format indicated by the interface parameters needs to be regenerated), and if the new interface parameters are not regenerated, the newly added interface may not be used. When the code is generated, the compiling process needs to be performed again, and the compiling process may also require the service end to suspend the service, so that a great limitation may be caused to the client, that is, the client may not be able to access other services.

In the embodiment of the present disclosure, after the generated target request is detected, the target interface parameter may be directly obtained from the preset interface parameter list according to the target request name of the target request, and the first request data may be generated based on the target interface parameter and the content of the target request, and the first request data may be responded by the server of the server and receive the return value. That is, it can be understood that: the client does not limit the specific interface parameters, but acquires the corresponding interface parameters according to the request name of the request. That is, when the client sends any request service, the client does not need to suspend its own service, thereby simplifying the RPC calling process. That is, it can be understood that in this way, the client does not need to generate an RPC call code during the call process of adding RPC.

It can be seen that, because the interface parameters of each interface are not required to be fixed in advance, the generalized call of the RPC can be realized.

In some embodiments, step 102 (generating first request data based on the target interface parameter and the target request, and sending the first request data to the server indicated by the target request) may specifically be:

and analyzing the target interface function to obtain a first analysis result, reading target request content in the target request, and generating first request data according to the first analysis result and the target request content.

In some embodiments, a syntax tree may be built for the IDL, and the built syntax tree may parse the target interface parameters and read the target request content in the target request. It should be noted that there are many ways to establish a syntax tree for IDL, and in a specific embodiment, only reasonable setting needs to be performed according to actual situations, and for simplicity of the description, details are not repeated here.

In some embodiments, when the format of the target request content is a nested format, a recursive call needs to be made to the target request content. For the nested type map, the Key and Value in the map need to be read one by one, and the read process of Key and Value also needs to be recursively processed.

In some embodiments, the interface parameters specify fields and formats for sending data by the client and the server, and since the Kael library is used for sending data to the server in the technical solution disclosed in the present disclosure, in order that a target request generated by the client can be correctly read by the Kael library, the client may agree on the format of the target request when generating the target request and submitting the target request to the Kael library, so that the Kael library can correctly obtain target request content of the target request.

Thus, in some embodiments, prior to step 102 (generating first request data based on the target interface parameters and the target request, and sending the first request data to the server indicated by the target request), the data format of the target request may also be determined; in response to determining that the data format of the target request is not any of the at least one preset data format, a prompt indicating that the target request cannot be sent may be generated. Correspondingly, after the user knows the prompt message, the data format of the transmitted target request can be changed, so that the target request can be transmitted.

In some embodiments, the at least one datum may include: JSON format, format of data type description such as map, slice, etc. in Golang language, etc.

In some embodiments, since the JSON format is very common, almost all languages support this format. This allows any language to use the Kael library to make calls to any RPC, making the Kael library more versatile.

In some embodiments, the target request and corresponding return value are described in accordance with the JSON format, which may allow the Kael library to read the contents within the target request and corresponding return value.

In some embodiments, the preset interface parameter list may be generated by:

acquiring an interface parameter path table; acquiring interface parameters according to the interface parameter path table; and generating a preset interface parameter list according to the acquired interface parameters and the corresponding request names.

Here, the interface parameter path table includes: the interface parameter stores the correspondence between the address and the request name.

In some embodiments, a unified interface parameter repository may be provided, and the interface parameter repository may be configured to store all interface parameters and generate a corresponding path when each interface parameter is stored. That is, it can be understood that each interface parameter has a corresponding interface parameter storage address, and each interface parameter has a corresponding request name, so that the request name and the interface parameter storage address can be stored correspondingly by using the interface parameter path table.

In some embodiments, when it is determined that the interface parameter storage address in the interface parameter path table is changed, a new interface parameter may be acquired according to the changed interface parameter storage address, and the preset interface parameter list may be updated according to the acquired new interface parameter.

In some embodiments, the Kael library may obtain the interface parameter path table once at regular time (of course, in some implementation manners, the interface parameter path table may also be obtained according to an operation performed by a user, for example, after the user sends a certain instruction, the Kael library obtains the interface parameter path table), and may determine an interface parameter storage address newly added in the interface parameter path table, and may obtain a corresponding interface parameter (a new interface parameter) according to the newly added interface parameter storage address, and since the obtained new interface parameter is not stored in the original preset interface parameter list, the preset interface parameter list in the Kael library may be updated.

To facilitate understanding of differences between the technical solutions provided by the present application and the prior art, the following detailed description is made with reference to fig. 2, where fig. 2 is an exemplary interaction diagram provided by the embodiment of the present disclosure, and in fig. 2, a server a may be understood as a client and a server B may be understood as a server. The server A comprises a Kael library, when the server A needs to send a request to the server B, the server A sends the request to the Kael library firstly, and the Kael library obtains an interface parameter corresponding to the request according to the request name of the request. And then analyzing the corresponding interface parameters and reading request contents, and generating data in a specified format according to a preset generating function, wherein the data in the specified format is in a data format preset by the server A and the server B. When the data in the specified format is sent to the server B, the server B can acquire the content required by the server A and can return the content. However, since the returned content is in the data format of the server B, the Kael library is also required to convert the returned content into the data format that the server a can respond to, and when the server a receives the returned content, the server a and the server B complete one remote call.

Compared with the prior art, in the whole calling process, the server A only generates the request, and the server A does not need to: determining the request content, determining the interface parameters, converting the request content into the specified data format, etc., so that the server a does not need to store a fixed interface parameter file (for recording the interfaces that can be called and the interface parameters for responding), so that the server a can send any call request according to the specified data format. That is, because the Kael library dynamically maintains the preset interface parameter list, it can support to process the data of any RPC call conforming to the specified format, and in the prior art, whenever there is a new RPC call service, it needs to add corresponding code in the server a, and perform compiling operation. When a server serves a gateway product, if each new RPC service needs to modify the code of the gateway service and compile and run, it is obviously inconvenient and difficult to implement. Therefore, a Kael library which is used for maintaining the interface parameter file and analyzing the interface parameter file is added to the client, so that RPC service is wider.

With further reference to fig. 3, as an implementation of the method shown in the above-mentioned figures, the present disclosure provides an embodiment of a data invoking device, which corresponds to the embodiment of the data invoking method shown in fig. 1, and which can be specifically applied to various electronic devices.

As shown in fig. 3, the data calling apparatus of the present embodiment includes: an obtainingunit 301, configured to, in response to detecting that a target request is generated, obtain, according to a target request name of the target request, a target interface parameter corresponding to the target request name from a preset interface parameter list, where the preset interface parameter list includes: requesting the corresponding relation between the name and the interface parameter; agenerating unit 302, configured to generate first request data based on the target interface parameter and the target request, and send the first request data to a server indicated by the target request, where the server is capable of reading the first request data; a receivingunit 303, configured to receive a return value, where the server generates the return value according to the received first request data.

In some embodiments, the apparatus further includes alist generating unit 305, specifically configured to obtain an interface parameter path table, where the interface parameter path table includes: the corresponding relation between the interface parameter storage address and the request name; acquiring interface parameters according to the interface parameter path table; and generating the preset interface parameter list according to the acquired interface parameters and the corresponding request names.

In some embodiments, thelist generating unit 305 is further specifically configured to: in response to determining that the interface parameter storage address in the interface parameter path table is changed, acquiring a new interface parameter according to the changed interface parameter storage address; and updating the preset interface parameter list according to the acquired new interface parameters.

In some embodiments, the generatingunit 302 is specifically configured to: analyzing the target interface parameter to obtain a first analysis result; reading the target request content of the target request; and generating the first request data according to the first analysis result and the target request content.

In some embodiments, before generating the first request data based on the target interface parameter and the target request, the apparatus further includes a determiningunit 304 for determining a data format of the target request; and returning the target request in response to determining that the data format of the target request is not any one of at least one preset data format.

In some embodiments, the at least one predetermined data format includes: the JSON format.

Referring to fig. 4, fig. 4 illustrates an exemplary system architecture to which the data call method of one embodiment of the present disclosure may be applied.

As shown in fig. 4, the system architecture may includeterminal devices 401, 402, 403, anetwork 404, and aserver 405. Thenetwork 404 may be the medium used to provide communication links between theterminal devices 401, 402, 403 and theserver 405.Network 404 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

Theterminal devices 401, 402, 403 may interact with aserver 405 over anetwork 404 to receive or send messages or the like. Theterminal devices 401, 402, 403 may have various client applications installed thereon, such as a web browser application, a search-type application, and a news-information-type application. The client application in theterminal device 401, 402, 403 may receive the instruction of the user, and complete the corresponding function according to the instruction of the user, for example, add the corresponding information to the information according to the instruction of the user.

Theterminal devices 401, 402, and 403 may be hardware or software. When theterminal devices 401, 402, and 403 are hardware, they may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III, mpeg compression standard Audio Layer 3), MP4 players (Moving Picture Experts Group Audio Layer IV, mpeg compression standard Audio Layer 4), laptop portable computers, desktop computers, and the like. When theterminal devices 401, 402, and 403 are software, they can be installed in the electronic devices listed above. It may be implemented as multiple pieces of software or software modules (e.g., software or software modules used to provide distributed services) or as a single piece of software or software module. And is not particularly limited herein.

Theserver 405 may be a server providing various services, for example, receive an information acquisition request sent by theterminal devices 401, 402, and 403, and acquire, according to the information acquisition request, presentation information corresponding to the information acquisition request in various manners. And the relevant data of the presentation information is sent to theterminal devices 401, 402, 403.

It should be noted that the information processing method provided by the embodiment of the present disclosure may be executed by a terminal device, and accordingly, the data calling device may be disposed in theterminal devices 401, 402, and 403. Furthermore, the information processing method provided by the embodiment of the present disclosure may also be executed by theserver 405, and accordingly, an information processing apparatus may be provided in theserver 405.

It should be understood that the number of terminal devices, networks, and servers in fig. 4 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to fig. 5, shown is a schematic diagram of an electronic device (e.g., a terminal device or a server of fig. 4) suitable for use in implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, a mobile terminal such as a mobile phone, a notebook computer, a digital broadcast receiver, a PDA (personal digital assistant), a PAD (tablet computer), a PMP (portable multimedia player), a vehicle terminal (e.g., a car navigation terminal), and the like, and a stationary terminal such as a digital TV, a desktop computer, and the like. The electronic device shown in fig. 5 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present disclosure.

As shown in fig. 5, the electronic device may include a processing means (e.g., central processing unit, graphics processor, etc.) 501 that may perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM)502 or a program loaded from a storage means 508 into a Random Access Memory (RAM) 503. In theRAM 503, various programs and data necessary for the operation of the electronic apparatus 500 are also stored. Theprocessing device 501, the ROM502, and theRAM 503 are connected to each other through abus 504. An input/output (I/O)interface 505 is also connected tobus 504.

Generally, the following devices may be connected to the I/O interface 505:input devices 506 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.;output devices 507 including, for example, a Liquid Crystal Display (LCD), speakers, vibrators, and the like;storage devices 508 including, for example, magnetic tape, hard disk, etc.; and acommunication device 509. The communication means 509 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. While fig. 5 illustrates an electronic device having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided.

In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a non-transitory computer readable medium, the computer program containing program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication means 509, or installed from the storage means 508, or installed from theROM 502. The computer program performs the above-described functions defined in the methods of the embodiments of the present disclosure when executed by theprocessing device 501.

It should be noted that the computer readable medium in the present disclosure can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In contrast, in the present disclosure, a computer readable signal medium may comprise a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.

In some embodiments, the clients, servers may communicate using any currently known or future developed network Protocol, such as HTTP (HyperText Transfer Protocol), and may interconnect with any form or medium of digital data communication (e.g., a communications network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future developed network.

The computer readable medium may be embodied in the electronic device; or may exist separately without being assembled into the electronic device.

The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to detecting that a target request is generated, according to a target request name of the target request, acquiring a target interface parameter corresponding to the target request name from a preset interface parameter list, wherein the preset interface parameter list comprises: requesting the corresponding relation between the name and the interface parameter; generating first request data based on the target interface parameters and the target request, and sending the first request data to a server indicated by the target request, wherein the server can read the first request data; and receiving a return value, wherein the server generates the return value according to the received first request data.

Computer program code for carrying out operations for the present disclosure may be written in any combination of one or more programming languages, including but not limited to an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units described in the embodiments of the present disclosure may be implemented by software or hardware. The name of the unit does not in some cases constitute a limitation to the unit itself, and for example, the obtainingunit 301 may also be described as a "unit that obtains target interface parameters corresponding to the target request name.

The functions described herein above may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Application Specific Standard Products (ASSPs), systems on a chip (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the disclosure herein is not limited to the particular combination of features described above, but also encompasses other embodiments in which any combination of the features described above or their equivalents does not depart from the spirit of the disclosure. For example, the above features and (but not limited to) the features disclosed in this disclosure having similar functions are replaced with each other to form the technical solution.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (10)

1. A data calling method, characterized in that the method comprises:

in response to detecting that a target request is generated, according to a target request name of the target request, acquiring a target interface parameter corresponding to the target request name from a preset interface parameter list, wherein the preset interface parameter list comprises: requesting the corresponding relation between the name and the interface parameter;

generating first request data based on the target interface parameters and the target request, and sending the first request data to a server indicated by the target request, wherein the server can read the first request data;

and receiving a return value, wherein the server generates the return value according to the received first request data.

2. The method of claim 1, wherein the list of preset interface parameters is generated by:

obtaining an interface parameter path table, wherein the interface parameter path table includes: the corresponding relation between the interface parameter storage address and the request name;

acquiring interface parameters according to the interface parameter path table;

and generating the preset interface parameter list according to the acquired interface parameters and the corresponding request names.

3. The method of claim 2, further comprising:

in response to determining that the interface parameter storage address in the interface parameter path table is changed, acquiring a new interface parameter according to the changed interface parameter storage address;

and updating the preset interface parameter list according to the acquired new interface parameters.

4. The method of claim 1, wherein generating first request data based on the target interface parameters and the target request comprises:

analyzing the target interface parameter to obtain a first analysis result;

reading target request content of the target request;

and generating the first request data according to the first analysis result and the target request content.

5. The method of claim 1, wherein prior to generating first request data based on the target interface parameters and the target request, the method further comprises:

determining a data format of the target request;

in response to determining that the data format of the target request is not any of at least one preset data format, generating a prompt indicating that the target request cannot be sent.

6. The method of claim 1, wherein the at least one predetermined data format comprises: the JSON format.

7. A data call apparatus, comprising:

an obtaining unit, configured to, in response to detecting that a target request is generated, obtain, according to a target request name of the target request, a target interface parameter corresponding to the target request name from a preset interface parameter list, where the preset interface parameter list includes: requesting the corresponding relation between the name and the interface parameter;

a generating unit, configured to generate first request data based on the target interface parameter and the target request, and send the first request data to a server indicated by the target request, where the server is capable of reading the first request data;

and the receiving unit is used for receiving a return value, wherein the server generates the return value according to the received first request data.

8. The apparatus according to claim 7, wherein the generating unit is specifically configured to:

analyzing the target interface parameter to obtain a first analysis result;

reading target request content of the target request;

and generating the first request data according to the first analysis result and the target request content.

9. An electronic device, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-6.

10. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-6.

Images