WO2019052526A1 - Api调用系统、方法、装置、电子设备及存储介质 - Google Patents

Api调用系统、方法、装置、电子设备及存储介质 Download PDF

Info

Publication number
WO2019052526A1
WO2019052526A1 PCT/CN2018/105648 CN2018105648W WO2019052526A1 WO 2019052526 A1 WO2019052526 A1 WO 2019052526A1 CN 2018105648 W CN2018105648 W CN 2018105648W WO 2019052526 A1 WO2019052526 A1 WO 2019052526A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
target
calling
server
request
Prior art date
Application number
PCT/CN2018/105648
Other languages
English (en)
French (fr)
Inventor
黄鑫
徐梓耀
Original Assignee
北京金山云网络技术有限公司
北京金山云科技有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京金山云网络技术有限公司, 北京金山云科技有限公司 filed Critical 北京金山云网络技术有限公司
Publication of WO2019052526A1 publication Critical patent/WO2019052526A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/562—Brokering proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Definitions

  • the present application relates to the field of Internet technologies, and in particular, to an API calling system, method, device, electronic device, and storage medium.
  • a network operator For a network operator, it usually operates a plurality of services, such as a cloud host service, a database service, etc., each of which is implemented by an application in a corresponding service server, and each service server is provided with API (Application Programming Interface), for the programmer to modify the application corresponding to the service by calling the API corresponding to the service.
  • API Application Programming Interface
  • the API calling device when the API calling device invokes an API, the API calling device sends a call request to the service server where the API is located, and the service server where the API is located first needs to determine whether the calling request satisfies the calling condition, for example, determining the calling request. Whether it is legal and can be authenticated by signature and permission, the API call device is allowed to call the API only if the judgment result is yes.
  • Each service server needs to have the ability to determine whether the call request satisfies the calling condition, that is, each service server. Both must provide additional resources to achieve this capability, resulting in wasted business server resources.
  • the purpose of the embodiments of the present application is to provide an API calling system, apparatus, method, electronic device, and storage medium, so as to prevent each service server from providing additional resources to implement the ability to determine whether the calling request satisfies the calling condition.
  • the waste of resources are as follows:
  • an embodiment of the present application provides an API calling system, including: a gateway server, an API calling device, and a service server provided with an API, where the API invokes a target API in the device to invoke the device, And the method is configured to: send a call request for the target API to the gateway server; receive a call result that is sent by the gateway server for the call request; and the gateway server is configured to receive the call request sent by the target API calling device, and determine whether the call request satisfies the call.
  • a preset condition of the target API if the call request satisfies a preset condition for calling the target API, forwarding the call request to a target service server where the target API is located; receiving a call result sent by the target service server, and calling the call The result is fed back to the target API calling device, wherein the result of the call is obtained by the target service server processing the call request; the target service server is configured to receive the call request forwarded by the gateway server; and the call request is processed to obtain the call result; The result of the call is sent to the net Turn off the server.
  • an embodiment of the present application provides an API calling method, which is applied to a gateway server, where the method includes: receiving a call request for a target API sent by a target API calling device; determining whether the calling request satisfies a calling target API. a preset condition; if the call request satisfies a preset condition of the calling target API, the call request is forwarded to the target service server where the target API is located; the call result sent by the target service server is received, and the call result is fed back to the target API call.
  • the device wherein the result of the call is obtained by the target service server processing the above call request.
  • an embodiment of the present application provides an API calling apparatus, which is applied to a gateway server in an API calling system, where the API calling system further includes an API calling device and a service server provided with an API, where the device includes: a receiving module, The receiving module is configured to receive a call request for the target API sent by the target API calling device, and the determining module is configured to determine whether the calling request meets a preset condition of the calling target API, and the forwarding module is configured to determine that the determining result of the module is yes.
  • the call request is forwarded to the target service server where the target API is located; the feedback module is configured to receive the call result sent by the target service server, and feed the call result to the target API calling device, where the call result is the target service.
  • the server obtained by processing the call request.
  • an embodiment of the present application provides an electronic device, including a processor and a memory, where: a memory is used to store a computer program; and a processor is configured to implement any of the foregoing APIs when executing a program stored on the memory. Call the method steps described in the method.
  • the embodiment of the present application provides a computer readable storage medium, where the computer readable storage medium stores a computer program, and when the computer program is executed by the processor, implements the method steps described in any of the API calling methods. .
  • an embodiment of the present application provides a computer program product comprising instructions, when executed on a computer, causing a computer to execute the method steps described in any of the API calling methods described above.
  • the embodiment of the present application provides a computer program that, when run on a computer, causes the computer to execute the method steps described in any of the API calling methods described above.
  • the API calling system includes: a gateway server, an API calling device, and a service server provided with an API, wherein the target API calling device in the API calling device is used to the gateway server.
  • the gateway server is configured to receive a call request sent by the target API calling device; and determining whether the call request satisfies a preset condition of the calling target API If yes, the call request is forwarded to the target service server where the target API is located; the call result sent by the target service server is received, and the call result is fed back to the target API calling device; and the target service server is used to receive the forwarding by the gateway server.
  • the task of determining whether the calling request satisfies the calling condition is all completed by the gateway server, and the service server in the API calling system does not need to perform a task of determining whether the calling request satisfies the calling condition.
  • the solution provided by the embodiment of the present application can also prevent the staff from performing development work on the judgment capability corresponding to the foregoing task in the service server in the process of developing the API, that is, determining whether the call request satisfies the calling condition of the task from the service.
  • the server is stripped out to facilitate the development of the API in the service server by the staff. Therefore, the maintenance and development cost of the API in the service server is low in the solution provided by the embodiment of the present application.
  • FIG. 1 is a schematic structural diagram of an API calling system according to an embodiment of the present application
  • FIG. 2 is a schematic structural diagram of an API calling system according to another embodiment of the present application.
  • FIG. 3 is a schematic structural diagram of an API calling system according to still another embodiment of the present application.
  • FIG. 4 is a schematic diagram of an internal organization structure of a gateway server involved in an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of an API calling system according to another embodiment of the present disclosure.
  • FIG. 6 is a signaling diagram of a process for issuing a management command involved in an embodiment of the present application
  • FIG. 7 is a schematic structural diagram of an API calling system according to another embodiment of the present disclosure.
  • FIG. 8 is a signaling diagram of an API calling process involved in an embodiment of the present application.
  • FIG. 9 is a schematic flowchart of an API calling method according to an embodiment of the present disclosure.
  • FIG. 10 is a schematic flowchart diagram of an API calling method according to another embodiment of the present disclosure.
  • FIG. 11 is a schematic flowchart diagram of an API calling method according to still another embodiment of the present application.
  • FIG. 12 is a schematic flowchart diagram of an API calling method according to another embodiment of the present disclosure.
  • FIG. 13 is a schematic structural diagram of an API calling apparatus according to an embodiment of the present disclosure.
  • FIG. 14 is a schematic structural diagram of an API calling apparatus according to another embodiment of the present disclosure.
  • FIG. 15 is a schematic structural diagram of an API calling apparatus according to still another embodiment of the present application.
  • FIG. 16 is a schematic structural diagram of an API calling apparatus according to another embodiment of the present disclosure.
  • FIG. 17 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
  • the API is a predefined function that is designed to give developers the ability to access a set of routines based on a piece of software or hardware without having to access the source code or understand the details of the internal workings.
  • the API calling device in the present application file, refers to a device that invokes an API, such as a user terminal device, a management device of an operator, and a control device.
  • the specific type of the API calling device is not limited in the present application, as long as it is Just call the device of the API.
  • An API calling system provided by the embodiment of the present application includes: a gateway server, an API calling device, and a service server provided with an API.
  • FIG. 1 is a schematic structural diagram of an API calling system according to an embodiment of the present application.
  • the API calling system includes a gateway server, a target API calling device, an API calling device 1 to m, a target service server, and a service server 1 to n. .
  • m and n are both greater than or equal to 1, that is, in the API calling system, the number of API calling devices and service servers are greater than or equal to 2.
  • the foregoing API calling device may include the foregoing target API calling device and the API calling device 1 to m, but is not limited thereto.
  • API calling devices included in the above-mentioned API calling system shown in the embodiment of the present application may also be one, which is not limited by the embodiment of the present application.
  • the number of API calling devices and the number of service servers may be multiple.
  • the API calling device may be a user terminal device, a management device of an operator, or a control device of an operator; and a plurality of service servers are usually owned by the same operator, for example, a service server provided by the same company A to provide a cloud host service. 1 and a business server 2 that provides database services.
  • the type of the API set in the service server may be an open API (open API), or may be other types of APIs.
  • the embodiment of the present application does not limit the specific type of the API.
  • the API calling device directly communicates with the service server, and in the embodiment of the present application, in the process of calling the API, communication between any API calling device and any service server is through the gateway server. Upon completion, there is no direct communication between the API calling device and the business server.
  • the target API calling device in each API calling device provided by the embodiment of the present application is configured to send a call request for the target API to the gateway server, and receive a call result for the call request fed back by the gateway server.
  • the target API calling device as the calling request sending end described herein is only a name given for convenience of explaining the specific operation.
  • the API calls any one of the API calling devices in the system. Both can call the device as the target API that sends the call request.
  • the API calling device when any API calling device sends a calling request for an API to the gateway server, the API calling device calls the device as the target API, and the API is called the target API.
  • the API and the user terminal device are respectively the target API and the target API call device in the embodiment of the present application.
  • the target API calling device may generate the above-mentioned calling request for the target API.
  • the target API calling device is provided with a user input interface, and the user inputs a command information of the calling target API in the user input interface, and the target API calling device may according to the command.
  • the information generates a call request for the target API.
  • the specific implementation manner in which the target API calling device obtains the calling request for the target API may be implemented by using a related technology, and the embodiment of the present application is not described in detail herein.
  • the gateway server is configured to receive the foregoing call request sent by the target API calling device, determine whether the calling request satisfies a preset condition of the calling target API, and forward the calling request to the call request if the calling request satisfies a preset condition of the calling target API.
  • the target service server where the target API is located; receives the call result sent by the target service server, and feeds the call result to the target API calling device; wherein the call result described herein is obtained by the target service server processing the call request.
  • the gateway server in the embodiment of the present application first determines whether the call request satisfies the preset condition of the target API, and only if the preset condition is met, the gateway server The calling request is forwarded to the target service server corresponding to the target API; and if the preset condition is not met, the gateway server does not forward the call request, for example, the calling request does not satisfy the preset condition of the calling target API.
  • the gateway server can directly discard the call request and send a message to the target API calling device to reject the call.
  • the API calling device when an API calling device invokes an API, the API calling device sends a call request to the service server where the API is located, and the service server where the API is located first needs to determine whether the calling request satisfies the calling condition;
  • the target API calling device first sends a call request to the gateway server, and then the gateway server determines whether the call request satisfies the preset condition of the calling target API.
  • the preset condition in the embodiment of the present application may be exactly the same as the calling condition in the related art, except that the main body performing the judgment operation herein is different.
  • the service server determines whether the call request satisfies the condition x, and if so, starts processing the call request.
  • the gateway server also determines whether the call request satisfies the condition x, and if so, the call is made. The request is forwarded to the business server where the API is located.
  • the determining, by the gateway server, whether the received call request meets the preset condition of the calling target API may include: obtaining internal service information of the target API, where the internal service information includes the target The address information of the API, the operation type of the calling target API, and the required resource type; verifying the legality and security of the calling request based on the operation type and the required resource type of the calling target API; judging legality and security If the verification result is passed, if the determination result is passed, it is determined that the calling request satisfies the preset condition of the calling target API, and if the determination result is not passed, it is determined that the calling request does not satisfy the preset condition of the calling target API; And if the result of the determination is that the gateway server forwards the call request to the target service server where the target API is located, the gateway server may: forward the call request to the target API according to the obtained address information.
  • Target business server if the gateway server forwards the call request to the target API according to the obtained address information.
  • the address information of the target API may include an IP address (Internet Protocol Address) and/or a MAC (Media Access Control) address of the service server (ie, the target service server) where the target API is located. And the interface address of the target API in the target service server, but is not limited to this.
  • the operation types of the above-mentioned calling target API may include common POST operations and GET operations, etc.; the required resource types of the target API are called, and in the case of calling the API to close the operation of the cloud host, the required resource type is cloud. Host; in the case of calling the API to close the database, the required resource type is the database; in the case of calling the API for network bandwidth upgrade, the required resource type is bandwidth.
  • the internal service information of the target API includes information required for authenticating the call request of the target API, and is not limited to the operation type and required of the above-mentioned target API.
  • the information included in the above-mentioned internal service information may be set by a person skilled in the art according to the actual requirements of the legality verification.
  • the specific content included in the internal service information is not limited herein.
  • the verification of the security by the gateway server may be expressed as at least one of the following, but is not limited thereto: the gateway server verifies whether the calling request of the target API carries a Trojan or a virus, and if the Trojan or virus is carried, the target is determined. The calling request of the API is invalid; if the Trojan or virus is not carried, it is determined that the calling request of the target API is legal. The gateway server verifies whether the number of calls of the target API to the target API reaches a preset threshold within a certain period of time. If the preset threshold is reached, it is determined that the target API call request is invalid; if the preset threshold is not reached, the target is determined. The API call request is legal.
  • the foregoing preset condition of the calling target API may include: the above-mentioned calling request for the target API passes the verification of legality and security.
  • the gateway server first obtains internal service information of the target API, and the obtained target internal service information includes address information of the target API, an operation type of the calling target API, and a required resource type. Then, the gateway server verifies the legality and security of the calling request based on the operation type and the required resource type of the calling target API. After the verification is passed, the gateway server will invoke the address information carried in the internal service information. The request is forwarded to the target business server where the target API is located.
  • the internal service information of all APIs in the API calling system can be stored locally in the gateway server, and when the gateway server receives the call request for the target API, the gateway server first Find the internal service information of the target API locally.
  • the gateway server locally stores a correspondence table between the identifier information of the API and the internal service information; and the gateway server receives the identifier information that carries the target API in the call request for the target API, and the gateway server according to the call request The identifier information carried is searched for the corresponding relationship table, and the internal service information corresponding to the identifier information, that is, the internal service information of the target API, is found.
  • the internal service information of all the APIs in the API calling system is stored locally in the gateway server, the internal service information will occupy the storage space of the gateway server, and the gateway server also needs to find the internal service information locally, and the search operation may be performed.
  • the CPU (Central Processing Unit) resource of the gateway server is consumed.
  • the above API calling system may further include a database server for storing internal service information of the API.
  • the obtaining, by the gateway server, the internal service information of the target API may include: the gateway server sending an acquisition request for the internal service information of the target API to the database server; and receiving the internal service information of the target API that is replied by the database server based on the acquisition request.
  • the database server may be configured to receive an acquisition request sent by the gateway server. According to the acquisition request, the internal service information of the target API is obtained locally, and the internal service information of the target API is sent to the gateway server.
  • the internal service information of the API is stored in an additionally configured database server in the API calling system.
  • the gateway server receives the calling request for the target API, the gateway server first generates an internal service information for the target API.
  • the obtaining request is sent to the database server.
  • the database server searches for the internal service information of the target API locally, and sends the internal service information of the target API to be searched to the gateway server.
  • the database server stores a correspondence table between the identifier information of the API and the internal service information.
  • the gateway server receives the call request carrying the identifier information of the target API, the gateway server generates an acquisition request carrying the identifier information, and then Sending the acquisition request to the database server, after receiving the acquisition request, the database server searches for the internal service information corresponding to the identification information locally according to the locally stored relationship table, and after searching, sends the found service information.
  • the gateway server obtains the internal service information of the target API.
  • the embodiment of the present application does not limit the kind of the database server, for example, it may be a common redis (a database) database server.
  • a database a database
  • multiple database servers can be deployed in the API calling system, and each database server exists in a master-slave mode, that is, one of the database servers in the master state is in a working state, which can be performed with the gateway server. Interaction; the remaining database servers in the slave state store the same data as the database server in the master state. When the database server in the master state fails, one of them is switched from the state database server to the new database. The state of the database server and interact with the gateway server.
  • the specific working manner of the foregoing multiple database servers in the master-slave mode may not be limited.
  • the gateway server determines whether the received call request satisfies the preset condition of the calling target API, and may also be: based on the signature carried in the received call request. , the signature of the call request and the verification of the authority; determine whether the verification of the signature and the permission is passed, and if the judgment result is passed, determine that the call request satisfies the preset condition of the calling target API; In the case, it is determined that the call request does not satisfy the preset condition of the calling target API.
  • the API calling device may first obtain a signature, which may be obtained by a preset signature calculation method, and the sent call request carries the signature obtained by the above calculation.
  • a signature which may be obtained by a preset signature calculation method
  • the sent call request carries the signature obtained by the above calculation.
  • the specific implementation method for obtaining the signature by the API calling device is not limited in the embodiment of the present application, as long as the API calling device can obtain the signature.
  • the verification of the signature and the permission of the call request that is, the AK (Access Key ID)/SK (Secret Access Key) is performed on the call request
  • the specific implementation manner of the verification may adopt the method in the related art, but The embodiment of the present application is not limited thereto, as long as the verification of the signature and the authority of the call request can be implemented.
  • the gateway server performs signature and permission verification on the call request based on the signature carried in the received call request.
  • the gateway server itself may utilize the received call request.
  • Signature, directly signing the call request and verifying the permission, that is, the signature and permission verification of the call request are all completed by the gateway server. In this case, the gateway server can quickly obtain verification results for signatures and permissions.
  • the gateway server needs to perform verification of the signature and the authority, which will inevitably consume resources such as the CPU of the gateway server; also, in order to reduce the consumption of the CPU of the gateway server, in another case, as shown in FIG. 1 or FIG. 2
  • the API calling system may further include an authentication server for verifying signatures and permissions.
  • the gateway server performs signature and permission verification on the call request based on the signature carried in the received call request, and the gateway server sends the signature and the permission verification request carrying the signature carried by the call request to the verification server.
  • the gateway server receives the verification result of the authentication server for the signature and permission verification request feedback.
  • the foregoing verification server may be configured to receive a signature and a rights verification request sent by the gateway server, and perform signature and permission verification on the call request according to the signature carried in the signature and the rights verification request, and obtain a verification result; The obtained verification result is sent to the gateway server.
  • the gateway server after receiving the above-mentioned calling request for the target API, the gateway server generates a signature and permission verification request, and the signature and the rights verification request carry the signature carried in the calling request; then the gateway server Send the generated signature and permission verification request to the authentication server.
  • the verification server After receiving the signature and the rights verification request, the verification server performs signature and permission verification on the call request according to the signature carried in the signature and the rights verification request, and obtains the verification result, and finally sends the obtained verification result to the gateway server.
  • the preset condition of the above-mentioned calling target API may be: the above-mentioned calling request for the target API is verified by the signature and the authority.
  • the gateway server first extracts the signature from the calling request, and then generates a signature and a rights authentication request carrying the signature, and then the gateway server sends the signature and the rights authentication request to the authentication server.
  • the verification server performs signature and permission authentication on the call request according to the signature carried by the signature and the rights authentication request, obtains the verification result as verification, and then sends the verification result to the gateway server.
  • the verification result received by the gateway server is the verification pass, and the gateway server forwards the call request to the target service server where the target API is located.
  • the preset condition of the calling target API may be: verifying the validity of the call request for the target API, and verifying the validity of the security by using the target API.
  • the preset condition can also be: verification of the signature and permission by the call request for the target API.
  • the above two implementation manners may be used in combination, that is, the preset conditions for calling the target API include: legality, security, and verification of signatures and permissions for the calling request of the target API;
  • the specific execution order of the verification of the legality, the verification of the security, and the verification of the signature and the privilege may be arbitrary, and the embodiment of the present application is not limited herein.
  • the target service server in the API calling system provided by the embodiment of the present application is configured to receive the foregoing call request forwarded by the gateway server; and process the call request to obtain a call result; and send the obtained call result to the gateway server.
  • the target service server when receiving the call request sent by the gateway server, the target service server does not need to perform any verification on the call request, directly processes the call request, obtains the call result, and sends the call result to the gateway.
  • the server so that the gateway server feeds back the result of the call to the target API calling device.
  • the target service server processes the call request, and the specific implementation manner of obtaining the call result may be not limited, that is, it may be implemented in the related art, or may not be.
  • each service server needs to first determine whether the call request satisfies the call when receiving the call request sent by the API call device.
  • the call request is processed only if the call condition is met, and the result of the call is obtained. Therefore, in order to satisfy the ability of the service server to determine whether the call request satisfies the call condition, each service server must provide additional resources to implement the above capabilities, resulting in waste of service server resources.
  • each service server receives a call request from an API call device. You can verify the legality and security of the call request. Therefore, in order to solve the above problem of resource waste, the present application completes an operation for determining whether the call request satisfies the calling condition for each service server through the gateway server.
  • each service server needs to consume additional resources to provide the ability to determine whether the calling request satisfies the calling condition.
  • the gateway server needs to be used to provide a judgment whether the calling request satisfies the calling.
  • the ability of the condition can avoid the problem of resource waste caused by providing additional resources for each service server to realize whether the call request meets the call condition.
  • the task of determining whether the calling request satisfies the calling condition is all completed by the gateway server, and the service server in the API calling system does not need to execute whether the calling request satisfies the calling condition.
  • the solution provided in this embodiment can also prevent the staff from performing development work on the judgment capability corresponding to the foregoing task in the service server during the process of developing the API, that is, determining whether the call request satisfies the call condition from the service server.
  • the system is stripped out to facilitate the development of the API in the service server by the staff. Therefore, the maintenance and development cost of the API in the service server is low in the solution provided by this embodiment.
  • At least two gateway servers may exist in the API calling system, and at least two gateway servers herein may exist in a master-slave mode. That is, one of the gateway servers in the main state is used to interact with the API calling device, the service server, etc. in the actual work; the remaining gateway servers in the slave state store the same data as the gateway server in the master state. And does not interact with the API calling device, the service server, etc., when the gateway server in the primary state fails, one of the gateway servers in the state transitions to the new gateway server in the primary state, and invokes the device with the above API. , business servers, etc. to interact.
  • the specific working manner of the foregoing at least two gateway servers in the master-slave mode may be the solution of the related art, or may not be, and the embodiment of the present application does not limit this.
  • the above at least two gateway servers may exist in a master-slave mode, but in this case, there is always only one available gateway server in the API calling system, and the ability of the system to determine whether the calling request satisfies the calling condition is not improved. . Therefore, in the embodiment of the present application, the at least two gateway servers may be in a live mode, and each of the at least two gateway servers has the same function.
  • the API calling system may further include a load balancer corresponding to the two gateways.
  • the target API calling device sends the call request
  • the call request is first sent to the load balancer, and the load balancer is used by the load balancer.
  • the gateway server may be a plug-in gateway based on openresty implementation.
  • openresty is a high-performance Web (World Wide Web) based on nginx (high-performance HTTP (HyperText Transfer Protocol) and reverse proxy server) and Lua (a lightweight and compact scripting language).
  • the World Wide Web) platform integrates a large number of sophisticated Lua libraries, third-party modules, and most of the dependencies to facilitate the creation of highly dynamic, highly scalable, dynamic web applications, Web services, and dynamic gateways. Openresty effectively turns it into a powerful universal web application platform by bringing together a variety of well-designed nginx modules.
  • the goal of openresty is to let Web services run directly inside the nginx service, taking advantage of nginx's non-blocking I/O (Input/Output) model, not only for HTTP client requests, but even for remote backends such as MySQL (a database) Management systems), PostgreSQL (a database management system), Memcached (a high-performance distributed memory object caching system), and Redis (a database) all perform consistent high-performance responses.
  • MySQL a database
  • PostgreSQL a database management system
  • Memcached a high-performance distributed memory object caching system
  • Redis a database
  • the web developer and the system engineer can use the Lua script language to mobilize various C (a general computer programming language) language modules and Lua modules supported by nginx, and quickly construct enough to be competent for 10K or even 1000K or more.
  • a high-performance gateway server that connects in a single machine.
  • the gateway server based on openresty has very high performance, and its organizational structure is as shown in FIG. 4 .
  • the nginx in the gateway server is implemented based on epoll (a function in the character device driver), so that the gateway server still maintains a small resource footprint in the face of large concurrency.
  • epoll a function in the character device driver
  • the gateway server processes any request, it fully utilizes the implementation skills of I/O multiplexing, which greatly reduces the number of processes within it.
  • the nginx worker process is merged with lua-vm (a virtual machine).
  • the internal service information of the API may be cached in the shared memory (shm) of the lua-vm memory and the nginx-worker (child process), for example, when the gateway server obtains the internal service information of the target API, lua -vm memory and nginx-worker's shared memory caches the obtained internal service information for 1 minute, so that within 1 minute, when the gateway server receives the call request for the target API again, it can directly from the local lua-
  • the internal service information of the target API is obtained in the vm memory and the shared memory of the nginx-worker. Therefore, the efficiency of obtaining the internal service information of the target API in the embodiment of the present application is very high.
  • the priority of the internal service information of the target server to obtain the target API may be set as: lua-vm memory, shared memory of nginx-worker, and database server. That is, the gateway server first obtains the internal service information of the target API from the lua-vm memory. If not, the internal service information of the target API is obtained from the shared memory of the nginx-worker, and if not obtained, the database server is not available. Get internal service information of the target API.
  • any pending request such as the above-mentioned calling request or verification request, is first obtained by the nginx-master (main process), and the nginx-master is directed to the pending request.
  • the socket (socket) handle is first sent to the nginx-worker (worker) that is resident by the nginx-master, and then the The socket handle sends the above request to nginx-worker.
  • the nginx-worker After receiving the above request, the nginx-worker forwards the request to the lua-vm corresponding to it one after another. After receiving the above request sent by nginx-worker, lua-vm first creates a coroutine (lua-coroutine), and the coroutine processes the request, for example, sending a signature and permission verification request to the verification server, and calling the request. Forward to the target business server, etc.
  • the nginx-master (which is the master process in nginx, that is, the main process, which can also be called a management process) is used to manage nginx-worker in nginx.
  • the nginx-worker is a worker process in nginx, that is, a child process. , also known as the worker process) is used in nginx to handle basic network events, both nginx-master and nginx-worker are in the form of processes.
  • lua-vm can refer to a lua-based virtual machine.
  • the API calling system may further include a service development device and a management server, based on the system embodiment shown in FIG. 2 .
  • the API calling system includes: a gateway server, a target API calling device, an API calling device 1 to m, a target service server, a service server 1 to n, a database server, a management server, a target service development device, and a service development.
  • Equipment 1 to x the API calling system includes: a gateway server, a target API calling device, an API calling device 1 to m, a target service server, a service server 1 to n, a database server, a management server, a target service development device, and a service development.
  • Equipment 1 to x Equipment 1 to x.
  • n and x are integers greater than or equal to zero.
  • the target service development device corresponding to the target API may be used to send a management instruction for the target API to the management server.
  • the above business development device may be a device used by a developer responsible for developing an API in the business server.
  • the target business development device may be provided with a user input interface, and the developer may input instruction information on the user input interface, and then the service development device generates a specific management instruction.
  • the management instruction herein may be any one of an online command, a offline command, a modified command, or a delete command for the target API.
  • the management server may be configured to receive a management instruction sent by the target service development device; verify whether the received management instruction is legal, and if it is legal, forward the management instruction to the database server;
  • Whether the verification management instruction here is legal may be whether the user corresponding to the verification management instruction has corresponding management authority, whether the user name and password are correct, and whether the access traffic reaches at least one of the upper limit values.
  • the verification of whether the management instruction is legal may use the solution in the related art, or may not be, the embodiment of the present application is not limited.
  • the API calling system may have at least two management servers, and each management server has the same function.
  • the API calling system may further include one corresponding to the at least two.
  • a load balancer of the management server when the target API calling device sends the management instruction, first sends a management instruction to the load balancer, and the load balancer selects one management server from the at least two management servers, and then sends the management command
  • the selected management server is further operated by the selected management server to verify whether the received management instruction is legal, and if the verification result is legal, the management instruction is forwarded to the database server.
  • the database server may be further configured to receive a management instruction forwarded by the management server, and update the internal service information of the locally stored API according to the management instruction.
  • the database server updates the internal service information of the locally stored API according to the management instruction, which can be understood as: the internal service information of the API stored locally by the database server as a whole, and the local storage obtained by the database server after performing the operation according to the management instruction.
  • the internal service information of the API is different from the internal service information of the API stored locally before the operation.
  • the management instruction When the management instruction is an online instruction for the target API, the management instruction carries the internal service information of the target API, and the database server does not have a record of the internal service information of the target API, so the database server needs to manage the instruction
  • the internal service information of the carried target API is recorded locally. Therefore, the internal service information of the database server updating the locally stored API can be understood as: the database server adds a local service information of the target API locally.
  • the database server When the management instruction is an offline or delete instruction for the target API, the database server locally has a record of the internal service information about the target API, so the database server needs to delete the internal service information of the target API from the local according to the management instruction. Therefore, the internal service information of the database server updating the locally stored API can be understood as: the database server deletes the internal service information of the target API from the local.
  • the management instruction When the management instruction is a modification instruction for the target API, the management instruction carries the internal service information of the modified target API, and the database server locally records the internal service information about the target API, so the database server needs to be localized.
  • the internal service information of the recorded target API is replaced with the internal service information of the target API carried by the management instruction. Therefore, the internal service information of the database server that updates the locally stored API can be understood as: replacing the internal service information of the target API recorded locally with the internal service information of the target API carried by the management instruction.
  • the management server locally can also store the internal service information of each API in the API calling system, so if the management server verifies that the received management instruction is legal, if the management instruction is an online command, offline
  • the management server may update the internal service information of the locally stored API according to the management instruction, and the specific update manner may refer to the implementation manner used by the database server to update the internal service information of the locally stored API.
  • the management instruction when the management instruction is a delete instruction, the management server does not need to delete the internal service information about the target API of the local record, that is, only the database server needs to delete the internal API of the target database locally recorded by the database server according to the management instruction.
  • Service Information in addition, in a case where the management server stores the internal service information of each API in the API calling system, the management instruction may also be a registration instruction for the target API, and when the database server determines that the registration instruction is legal, only the registration is required. The internal service information of the target API carried in the instruction is added to the local, and the registration instruction does not need to be sent to the database server.
  • the target service development device sends the management command as follows: the target service development device obtains the target API. Manage the instructions and send the management instructions to the management server. After receiving the management instruction, the management server first verifies whether the management instruction is legal. If it is legal, the internal service information of the locally stored API is updated based on the internal service information of the target API carried in the management instruction; and the management instruction is Sending to the database server, and sending the result of the management instruction to the target service development device, that is, the target service development device has successfully issued the management instruction. After receiving the management instruction, the database server directly updates the internal service information of the locally stored API based on the internal service information of the target API carried in the management instruction.
  • the gateway server can obtain the internal service information of the target API from the database server.
  • the developer needs the offline target API
  • the developer inputs the instruction information of the offline target API in the target business development device, and then the target business development device generates a offline instruction for the target API based on the instruction information, and
  • the offline command is sent to the management server, and the management server verifies that the offline command is legal, and the management server deletes the internal service information of the locally recorded target API, and sends the offline command to the database server, and the database server is the same.
  • the internal service information of the target API of the local record is deleted, and the offline operation of the target API is completed. It can be understood that, after the target API calling device calls the target API again, the gateway server cannot obtain the internal service information of the target API from the database server, and the target API calling device cannot call the target API.
  • the gateway server may set the priority of the internal service information of the target API to be: lua-vm memory, nginx-worker shared memory, database server, and management server.
  • the internal service information of each API is recorded.
  • the management server may further provide a function of registering a service, modifying a service, starting a service, stopping a service, and canceling a service for each service development device.
  • the service is provided by each service server, for example, a cloud host service; in the embodiment of the present application, the registration service can be understood as: storing the address information of the service server corresponding to the service in the management server; Modifying a service can be understood as: modifying the address information of the service server corresponding to the service stored in the management server and the database server; starting the service can be understood as: setting the state of the service server corresponding to the service to be accessible; stopping the service can be understood as: The status of the service server corresponding to the service is set to the inaccessible state, but the address information of the service server corresponding to the service is not deleted.
  • the logout service can be understood as: deleting the address information of the service server corresponding to the service.
  • the developer when a new access in the API calling system is an API, the developer does not need to develop a judgment on whether the calling request satisfies the calling condition on the service server where the API is located.
  • the function can directly implement the function based on the gateway server, which greatly reduces the access cost of the API in the API calling system.
  • the solution of the embodiment of the present application can ensure the fast access of the API.
  • the solution of the embodiment of the present application can implement the functions of online, offline, modification, registration, and deletion of the target API through the management server, and can also implement the functions of registering a service, modifying a service, starting a service, stopping a service, and canceling a service.
  • These functions are implemented by the management server integration, which can facilitate the setting of strict system state equations in the API calling system, ensuring that the system does not have data anomalies due to abnormal operations in the process of implementing the above functions.
  • the management server in the embodiment of the present application is based on silm (a PHP (Hypertext Preprocessor) micro-framework) + notorm (a lightweight orm (Object Relational Mapping) ) framework) implemented.
  • silm a PHP (Hypertext Preprocessor) micro-framework
  • notorm a lightweight orm (Object Relational Mapping) ) framework
  • the above silm+notorm is a set of classic components, which ensures the efficient execution efficiency while greatly reducing the development cost and ensuring the effectiveness of development to a certain extent.
  • the solution implemented by the foregoing functions in the management server has higher stability and is more uniform in environment deployment. Moreover, for developers, it is easy to control and manage their own services and APIs through the management server.
  • the API calling system may further include a log server; and FIG. 7 is taken as an example, as shown in FIG. 7, on the basis of the method embodiment shown in FIG.
  • the above API calling system may further include a log server.
  • the gateway server may be further configured to: after receiving the call result sent by the target service server, generate a target log for the calling process of the target API; and send the generated target log to the log server.
  • the above log server can be used to receive the target log sent by the gateway server and record the target log locally.
  • the manner in which the gateway server generates the target log may be the manner adopted by the related art, or may not be, and the embodiment of the present application is not limited. It can be understood that, for the API calling system, all the API calling processes generate logs by the gateway server, and the gateway server generates a unified log for each calling process, which greatly reduces the API calling system for each API calling process.
  • the heterogeneity rate of the generated logs which is of great significance for data mining through logs; for example, in the case where the API calling system also includes a management server and a business development device, the business development device can be retrieved through the management server. Log information stored in the log server for developers to view.
  • the embodiment of the present application may also implement log collection and processing based on a logstash (a tool for receiving, processing, and forwarding logs) + a log server + an elasticsearch (a search program) + a rabbitmq (a message queue) mode;
  • the model collects data generated by the Kop system in near real-time, and provides simple analysis capabilities quickly and freely through elasticsearch.
  • logstash can be deployed in the gateway server, and the rabbitmq in the API calling system can be deployed on different machines.
  • the exchanges a message forwarding module
  • the exchange uses a replica (a kind of The way to deploy the process, the exchange is deployed on multiple machines.
  • elasticsearch can be deployed on multiple machines, and elasticsearch uses replicat+sharding (sharding) deployment to ensure data availability.
  • Logstash offline maps the target log generated by the gateway server, converts the target log into json (JavaScript Object Notation) format; then logstash uses the durable mode (a message can not be received in time to prevent downtime and other exceptions) Design mode) Select an exchange from each exchange of rabbitmq, and pass the target log in json format to the selected exchange.
  • json JavaScript Object Notation
  • the selected exchange establishes two queues for the elasticsearch and the log server respectively; the queue also uses the durable mode to ensure the availability of unconsumed data. It can be understood that for the same log information, the exchange stores the log information in two queues at the same time, the elasticsearch can consume the log information in one of the queues, and the log server can consume the log information in another queue.
  • the consumption can be understood as use.
  • the elasticsearch can consume the log information in one of the queues, and obtain the log information in a real-time manner.
  • elasticsearch can store the log information acquired in a short period of time, and build an index for the newly acquired log information at intervals. For example, elasticsearch can store the log information acquired in the past 30 days, and the interval is 1 day. The newly acquired log information builds an index.
  • the log server can consume the log information in another queue, and then the obtained log information is permanently saved.
  • the calling process of the target API calling device in the API calling system for the target API is as follows: the target API calling device first calculates a signature according to a preset signature calculation method, and then generates a target API for carrying the signature. Call the request and send the generated call request to the gateway server.
  • the gateway server After receiving the call request for the target API sent by the target API calling device, the gateway server first generates an acquisition request for the target API internal service information, where the acquisition request carries the identification information of the target API; and then sends the acquisition request to the Database server.
  • the database server stores internal service information of each API in the API calling system, that is, a correspondence table between the identification information of each API and its internal service information is recorded.
  • the internal service information of the target API is obtained from the correspondence table of the local record by using the identification information of the target API carried in the acquisition request; and the internal service information of the target API is sent to the gateway.
  • a server wherein the internal service information of the target API includes address information of the target API, an operation type of the target API, and a required resource type.
  • the gateway server After receiving the internal service information of the target API sent by the database server, the gateway server performs legality verification on the call request based on the operation type of the target API and the required resource type, and in the case that the legality verification is passed, The request is invoked for security verification, and when the security verification is passed, a signature and a rights authentication request for the call request are generated, and the generated signature and the rights authentication request are sent to the verification server.
  • the verification server After receiving the signature and the rights authentication request, the verification server performs the signature and the authority authentication on the call request, obtains the verification result that is verified, and sends the verification result to the gateway server.
  • the gateway server forwards the call request to the target service server according to the address information of the target API.
  • the target service server After receiving the call request forwarded by the gateway server, the target service server directly processes the call request, obtains the call result, and sends the call result to the gateway server.
  • the gateway server After receiving the result of the foregoing call, the gateway server generates a target log for the calling process of the target API, and sends the target log to the log server (not shown in FIG. 8), and the log server receives the target log. After that, store the target log locally. In addition, the gateway server feeds back the received call result to the target API calling device to complete the call of the target API.
  • the embodiment of the present application provides an API calling method, which is applied to a gateway server.
  • the API calling method provided by the embodiment of the present application includes:
  • S101 Receive a call request sent by the target API calling device for the target API.
  • S102 Determine whether the received call request satisfies a preset condition for calling the target API.
  • step S103 is performed: forwarding the call request to the target service server where the target API is located.
  • S104 Receive a call result sent by the target service server, and feed back the result of the call to the target API calling device, where the result of the call is obtained by the target service server processing the call request.
  • the gateway server is disposed in an API calling system, and the API calling system may further include an API calling device and a service server configured with an API.
  • the step of determining whether the received call request meets a preset condition for invoking the target API may include:
  • S1021 Obtain internal service information of the target API, where the obtained internal service information includes address information of the target API, an operation type of calling the target API, and a required resource type;
  • S1022 verify validity and security of the call request based on the operation type and the required resource type of the calling target API;
  • S1023 determining whether the verification of the legality and the security is passed. If the judgment result is a pass, determining that the received call request satisfies the preset condition of the calling target API; if the judgment result is not passed, determining the The received call request does not satisfy the preset condition of the calling target API;
  • the step of forwarding the call request to the target service server where the target API is located may include:
  • the call request is forwarded to the target service server where the target API is located.
  • the API calling system may further include a database server for storing internal service information of the API,
  • the step of obtaining the internal service information (S1021) of the target API may include the following steps a and b:
  • Step a sending an acquisition request for internal service information of the target API to the database server; wherein the database service stores internal service information of the API;
  • Step b Receive internal service information of the target API that the database server replies based on the acquisition request.
  • the step of determining whether the received call request satisfies the preset condition (S102) of calling the target API may include:
  • S1024 Perform signature and permission verification on the call request based on the signature carried in the received call request.
  • S1025 determining whether the verification of the signature and the authority is passed. If the judgment result is a pass, determining that the call request satisfies the preset condition of the calling target API, and determining that the call request does not satisfy the call if the judgment result is not passed. Pre-set conditions for the target API.
  • the API calling system may further include an authentication server for verifying signatures and permissions.
  • the foregoing step of performing signature and permission verification (S1024) on the call request based on the signature carried in the received call request may include the following steps A and B:
  • Step A sending a signature and a rights verification request carrying the signature carried by the calling request to the verification server;
  • Step B Receive the verification result of the verification server for the signature and the authority verification request feedback.
  • the foregoing API calling system may further include a log server;
  • the method may further include:
  • S105 Generate a target log for a calling process of the target API
  • S106 Send the generated target log to the log server, so that the log server records the target log locally.
  • the task of determining whether the calling request satisfies the calling condition is all completed by the gateway server, and the service server in the API calling system does not need to execute whether the calling request satisfies the calling condition.
  • the solution provided in this embodiment can also prevent the staff from performing development work on the judgment capability corresponding to the foregoing task in the service server during the process of developing the API, that is, determining whether the call request satisfies the call condition from the service server.
  • the system is stripped out to facilitate the development of the API in the service server by the staff. Therefore, the maintenance and development cost of the API in the service server is low in the solution provided by this embodiment.
  • the embodiment of the present application further provides an API calling apparatus, which is applied to a gateway server, where the foregoing apparatus includes:
  • the receiving module 110 is configured to receive a call request for the target API sent by the target API calling device.
  • the determining module 120 is configured to determine whether the calling request meets a preset condition of the calling target API
  • the forwarding module 130 is configured to forward the call request to the target service server where the target API is located if the determination result of the determining module 120 is yes;
  • the feedback module 140 is configured to receive a call result sent by the target service server, and feed the call result to the target API calling device, where the call result is obtained by the target service server processing the call request.
  • the gateway server is disposed in an API calling system, and the API calling system may further include an API calling device and a service server configured with an API.
  • the foregoing determining module 120 may include:
  • the obtaining unit 1201 is configured to obtain internal service information of the target API, where the internal service information includes address information of the target API, an operation type of the calling target API, and a required resource type;
  • the first verification unit 1202 is configured to perform validity verification on the call request according to the operation type of the calling target API and the required resource type;
  • the first determining unit 1203 is configured to determine whether the verification of the legality and the security is passed, and if the determination result is a pass, determine that the calling request satisfies the preset condition of the calling target API; if the judgment result is not passed Determining that the call request does not satisfy the preset condition of the calling target API;
  • the forwarding module 130 may be configured to: when the determining result of the determining unit 1203 is YES, forward the calling request to the target service server where the target API is located according to the address information.
  • the above API calling system may further include a database server for storing internal service information of the API,
  • the obtaining unit 1201 may include:
  • a first sending subunit configured to send, to the database server, an acquisition request for internal service information of the target API, where the database server stores internal service information of the API;
  • the first receiving subunit is configured to receive internal service information of the target API that is returned by the database server based on the foregoing obtaining request.
  • the foregoing determining module 120 may include:
  • the second verification unit 1204 is configured to perform signature and permission verification on the call request based on the signature carried in the call request.
  • the second determining unit 1205 is configured to determine whether the verification of the signature and the authority is passed, and if the determination result is a pass, determine that the calling request satisfies a preset condition of the calling target API; and if the determination result is that the result is not passed, determine The above call request does not satisfy the preset condition of calling the target API.
  • the above API calling system further includes an authentication server for verifying signatures and permissions.
  • the foregoing second verification unit 1204 may include:
  • a second sending subunit configured to send, to the verification server, a signature and a rights verification request that carries the signature carried by the calling request;
  • the second receiving subunit is configured to receive a verification result of the verification server for the signature and the authority verification request feedback.
  • the above API calling system may further include a log server;
  • the foregoing apparatus may further include:
  • the generating module 150 is configured to generate a target log for the calling process of the target API after receiving the calling result sent by the target service server;
  • the sending module 160 sends the generated target log to the log server, so that the log server records the target log locally.
  • the task of determining whether the calling request satisfies the calling condition is all completed by the gateway server, and the service server in the API calling system does not need to execute whether the calling request satisfies the calling condition.
  • the solution provided in this embodiment can also prevent the staff from performing development work on the judgment capability corresponding to the foregoing task in the service server during the process of developing the API, that is, determining whether the call request satisfies the call condition from the service server.
  • the system is stripped out to facilitate the development of the API in the service server by the staff. Therefore, the maintenance and development cost of the API in the service server is low in the solution provided by this embodiment.
  • the embodiment of the present application further provides an electronic device, as shown in FIG. 17, including a processor 210 and a memory 220, wherein the memory 220 is configured to store a computer program, and the processor 210 is configured to execute the storage on the memory 220.
  • the API calling method shown in any of FIGS. 9 to 12 is implemented.
  • the electronic device may be provided with a communication interface for implementing communication between the electronic device and other devices.
  • the above-mentioned processor 210, communication interface, and memory 220 complete communication with each other through a communication bus.
  • the communication bus mentioned herein may be a Peripheral Component Interconnect (PCI) bus or an extended industry standard structure ( Extended Industry Standard Architecture, EISA) bus, etc.
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • the communication bus can be divided into an address bus, a data bus, a control bus, and the like.
  • the memory 220 may include a random access memory (RAM), and may also include a non-volatile memory (NVM), such as at least one disk storage.
  • NVM non-volatile memory
  • the memory may also be at least one storage device located away from the aforementioned processor.
  • the processor 210 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., or may be a digital signal processing (DSP), dedicated.
  • CPU central processing unit
  • NP network processor
  • DSP digital signal processing
  • ASIC Application Specific Integrated Circuit
  • FPGA Field-Programmable Gate Array
  • the foregoing electronic device may be the gateway server in the above embodiment, but is not limited thereto.
  • a computer readable storage medium having stored therein instructions that, when run on a computer, cause the computer to perform any of the above embodiments
  • the API call method
  • each service server in the API calling system does not need to perform whether to determine whether the calling request satisfies the call.
  • a conditional task that avoids the waste of resources caused by each business server providing additional resources to perform the task.
  • the task of determining whether the calling request satisfies the calling condition is all completed by the gateway server, and the staff member may be prevented from developing the judgment capability corresponding to the task in the service server during the process of developing the API.
  • each service server in the API calling system does not need to perform a task of determining whether the calling request satisfies the calling condition, and avoids that each service server needs to provide additional resources for performing the task.
  • the problem of wasted resources is all completed by the gateway server, and the staff member may be prevented from developing the judgment capability corresponding to the task in the service server during the process of developing the API.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请实施例提供了一种API调用系统、装置、方法、电子设备及存储介质。该API调用系统中，目标API调用设备，用于向网关服务器发送调用请求；接收网关服务器反馈的调用结果；网关服务器，用于判断该调用请求是否满足调用目标API的预设条件；如果是，将该调用请求转发给目标API所在的目标业务服务器；接收调用结果，并将该调用结果反馈给目标API调用设备；目标业务服务器，用于接收网关服务器转发的该调用请求；处理该调用请求，获得调用结果；将调用结果发送给网关服务器。本方案可以避免每个业务服务器均需要为执行判断调用请求是否满足调用条件的任务而提供额外的资源所造成的资源浪费问题。

Description

API调用系统、方法、装置、电子设备及存储介质
本申请要求于2017年9月14日提交中国专利局、申请号为201710825481.3发明名称为“API调用系统、方法、装置、电子设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网技术领域，特别是涉及API调用系统、方法、装置、电子设备及存储介质。
背景技术
对于网络运营商而言，其通常运营着多项业务，例如云主机业务、数据库业务等，每一项业务都由对应的业务服务器中的应用程序来实现，并且每个业务服务器中都设置有API(Application Programming Interface，应用程序编程接口)，以供编程人员通过调用业务对应的API来修改该业务对应的应用程序。
相关技术中，API调用设备调用某API时，API调用设备会向该API所在的业务服务器发送调用请求，该API所在的业务服务器首先需要判断该调用请求是否满足调用条件，例如，判断该调用请求是否合法且能够通过签名和权限的认证，只有在判断结果为是的情况下，才允许API调用设备调用该API。
但是，对于上述网络运营商而言，其拥有多个业务服务器，采用相关技术的方案实现API的调用，每个业务服务器中都需要具备判断调用请求是否满足调用条件的能力，即每个业务服务器中都必须要提供额外的资源以实现该上述能力，造成了业务服务器资源的浪费。
发明内容
本申请实施例的目的在于提供一种API调用系统、装置、方法、电子设备及存储介质，以避免每个业务服务器为实现判断调用请求是否满足调用条件的能力，均需要提供额外的资源而造成的资源浪费问题。具体技术方案如下：
为达上述目的，第一方面，本申请实施例提供了一种API调用系统，包括： 网关服务器、API调用设备以及设置有API的业务服务器，其中，上述API调用设备中的目标API调用设备，用于向网关服务器发送针对于目标API的调用请求；接收网关服务器反馈的针对上述调用请求的调用结果；网关服务器，用于接收目标API调用设备发送的上述调用请求；判断该调用请求是否满足调用目标API的预设条件；如果所述调用请求满足调用所述目标API的预设条件，将该调用请求转发给目标API所在的目标业务服务器；接收目标业务服务器发送的调用结果，并将该调用结果反馈给目标API调用设备，其中，该调用结果为目标业务服务器处理上述调用请求所获得的；目标业务服务器，用于接收网关服务器转发的上述调用请求；处理该调用请求，获得调用结果；将该调用结果发送给网关服务器。
第二方面，本申请实施例提供了一种API调用方法，应用于网关服务器，上述方法包括：接收目标API调用设备发送的针对于目标API的调用请求；判断该调用请求是否满足调用目标API的预设条件；如果该调用请求满足调用目标API的预设条件，将该调用请求转发给目标API所在的目标业务服务器；接收目标业务服务器发送的调用结果，并将该调用结果反馈给目标API调用设备，其中，该调用结果为目标业务服务器处理上述调用请求所获得的。
第三方面，本申请实施例提供了一种API调用装置，应用于API调用系统中的网关服务器，该API调用系统还包括API调用设备和设置有API的业务服务器，上述装置包括：接收模块，用于接收目标API调用设备发送的针对于目标API的调用请求；判断模块，用于判断该调用请求是否满足调用目标API的预设条件；转发模块，用于在判断模块的判断结果为是的情况下，将该调用请求转发给目标API所在的目标业务服务器；反馈模块，用于接收目标业务服务器发送的调用结果，并将调用结果反馈给目标API调用设备，其中，该调用结果为目标业务服务器处理该调用请求所获得的。
第四方面，本申请实施例提供了一种电子设备，包括处理器和存储器，其中：存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现上述任一API调用方法所述的方法步骤。
第五方面，本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，该计算机程序被处理器执行时实现上述任 一API调用方法所述的方法步骤。
第六方面，本申请实施例提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一API调用方法所述的方法步骤。
第七方面，本申请实施例提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述任一API调用方法所述的方法步骤。
由以上可知，本申请实施例提供的方案中，该API调用系统包括：网关服务器、API调用设备以及设置有API的业务服务器，其中，API调用设备中的目标API调用设备，用于向网关服务器发送针对于目标API的调用请求；接收网关服务器反馈的针对该调用请求的调用结果；网关服务器，用于接收目标API调用设备发送的调用请求；判断该调用请求是否满足调用目标API的预设条件；如果是，将该调用请求转发给目标API所在的目标业务服务器；接收目标业务服务器发送的调用结果，并将该调用结果反馈给目标API调用设备；目标业务服务器，用于接收网关服务器转发的该调用请求；处理该调用请求，获得调用结果；将所获得的调用结果发送给网关服务器。
与相关技术相比，本申请实施例提供的方案中，判断调用请求是否满足调用条件的任务全部由网关服务器完成，API调用系统中的业务服务器不需要执行判断调用请求是否满足调用条件的任务，避免了每个业务服务器均需要为执行该任务而提供额外的资源所造成的资源浪费问题。另外，本申请实施例提供的方案也可以避免工作人员在开发API的过程中，在业务服务器中进行关于上述任务所对应判断能力的开发工作，即，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的开发，所以本申请实施例提供的方案中针对业务服务器中API的维护和开发成本低。
附图说明
为了更清楚地说明本申请实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请一实施例提供的API调用系统的结构示意图；
图2为本申请另一实施例提供的API调用系统的结构示意图；
图3为本申请再一实施例提供的API调用系统的结构示意图；
图4为本申请实施例中涉及的网关服务器的内部组织结构示意图；
图5为本申请又一实施例提供的API调用系统的结构示意图；
图6为本申请实施例中涉及的管理指令下发过程的信令图；
图7为本申请又一实施例提供的API调用系统的结构示意图；
图8为本申请实施例中涉及的API调用过程的信令图；
图9为本申请一实施例提供的API调用方法的流程示意图；
图10为本申请另一实施例提供的API调用方法的流程示意图；
图11为本申请再一实施例提供的API调用方法的流程示意图；
图12为本申请又一实施例提供的API调用方法的流程示意图；
图13为本申请一实施例提供的API调用装置的结构示意图；
图14为本申请另一实施例提供的API调用装置的结构示意图；
图15为本申请再一实施例提供的API调用装置的结构示意图；
图16为本申请又一实施例提供的API调用装置的结构示意图；
图17为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
下面首先对本申请中涉及到的技术术语进行简单介绍。
API是预先定义的函数，其目的是为开发人员提供能够基于某软件或硬件 得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
API调用设备，在本申请文件中，其是指调用API的设备，例如用户终端设备、运营商的管理设备以及控制设备等，本申请文件中并不限定API调用设备的具体类型，只要是可以调用API的设备即可。
下面再通过具体实施例来对本申请进行详细介绍。
本申请实施例提供的一种API调用系统，包括：网关服务器、API调用设备以及设置有API的业务服务器。如图1所示的本申请一实施例提供的一种API调用系统的结构示意图，API调用系统包括网关服务器、目标API调用设备、API调用设备1～m、目标业务服务器以及业务服务器1～n。其中，m以及n均大于或等于1，即API调用系统中，API调用设备以及业务服务器的数量均大于或等于2。
需要说明的是，上述API调用设备可以包括上述目标API调用设备和API调用设备1～m，但并不限于此。
需要说明的是，本申请实施例所示的上述API调用系统包括的API调用设备的数量也可以为1个，本申请实施例并不对此做限定。
在本申请实施例的API调用系统中，API调用设备的数量以及业务服务器的数量均可以为多个。API调用设备可以是用户终端设备、运营商的管理设备或运营商的控制设备等；而多个业务服务器通常是同一运营商所拥有的，例如，同一公司A拥有的提供云主机服务的业务服务器1以及提供数据库服务的业务服务器2。另外，业务服务器中所设置的API的种类可以是openAPI(开放API)，也可以是其它类型的API，本申请实施例并不限定API的具体类型。
与相关技术不同的是，相关技术中，API调用设备与业务服务器直接通信，而本申请实施例中，调用API的过程中，任何API调用设备与任何业务服务器之间的通信均是通过网关服务器完成，API调用设备与业务服务器之间不进行直接通信。
本申请实施例提供的各个API调用设备中的目标API调用设备，用于向网关服务器发送针对于目标API的调用请求；接收网关服务器反馈的针对该调用请求的调用结果。
可以理解，此处所述的作为调用请求发送端的目标API调用设备，仅是为了方便说明具体操作而给定的名称，在实际应用中，根据业务需要，API调用系统中的任何一个API调用设备都可以作为发送调用请求的目标API调用设备。
类似的，上述目标API以及下述目标业务服务器均是为了方便说明具体操作而给定的名称而已。另外，本申请其他实施例中，也存在与前述类似的为了方便说明具体操作而给定名称的限定，其都是为了表述方便，并不是实质的限定作用。这里不再一一罗列。
在API调用系统中，任意一个API调用设备向网关服务器发送一个针对某API的调用请求时，称该API调用设备为目标API调用设备，称该API为目标API。例如，某用户终端设备针对某API发送了一个调用请求，则此时该API以及该用户终端设备分别为本申请实施例中的目标API以及目标API调用设备。
目标API调用设备可以生成上述针对目标API的调用请求，例如，目标API调用设备上设置有用户输入界面，用户在用户输入界面输入一个调用目标API的命令信息，则目标API调用设备可以根据该命令信息生成针对目标API的调用请求。当然，目标API调用设备得到针对目标API的调用请求的具体实现方式可以采用相关技术实现，本申请实施例在此不再详细介绍。
上述网关服务器，用于接收目标API调用设备发送的上述调用请求；判断该调用请求是否满足调用目标API的预设条件；如果该调用请求满足调用目标API的预设条件，将该调用请求转发给目标API所在的目标业务服务器；接收目标业务服务器发送的调用结果，并将调用结果反馈给目标API调用设备；其中，此处所述的调用结果为目标业务服务器处理上述调用请求所获得的。
可以理解，本申请实施例中的网关服务器在接收到关于目标API的调用请求时，先要判断该调用请求是否满足调用目标API的预设条件，只有在满足预设条件的情况下，网关服务器才会将调用请求转发给目标API对应的目标业务服务器；而在不满足预设条件的情况下，网关服务器不会将该调用请求转发出去，例如，调用请求不满足调用目标API的预设条件，网关服务器可以直接将该调用请求丢弃，并向目标API调用设备发送拒绝调用的信息。
如前背景技术所述，API调用设备调用某API时，API调用设备会向该API 所在的业务服务器发送调用请求，该API所在的业务服务器首先需要判断该调用请求是否满足调用条件；而在本申请实施例中，目标API调用设备首先会向网关服务器发送调用请求，然后由网关服务器判断该调用请求是否满足调用目标API的预设条件。可以理解，本申请实施例中的预设条件可以与相关技术中的调用条件完全相同，只是执行此处判断操作的主体不相同。
例如，相关技术中，API调用设备向某API所在的业务服务器发送调用请求后，该业务服务器判断该调用请求是否满足条件x，如果满足，则开始处理该调用请求。则相对应的，如果采用本申请实施例提供的方案，API调用设备向网关服务器发送针对某API的调用请求后，该网关服务器同样判断该调用请求是否满足条件x，如果满足，则将该调用请求转发给该API所在的业务服务器。
作为本申请实施例的一种可选实现方式，上述网关服务器判断所接收到的调用请求是否满足调用目标API的预设条件，可以包括：获得目标API的内部服务信息，该内部服务信息包括目标API的地址信息、调用目标API的操作类型和所需资源类型；基于调用目标API的操作类型和所需资源类型，对该调用请求进行合法性和安全性的验证；判断合法性和安全性的验证是否通过，在判断结果为通过的情况下，判定该调用请求满足调用目标API的预设条件，在判断结果为没有通过的情况下，判定该调用请求不满足调用目标API的预设条件；以及在判断结果为通过的情况下，即上述网关服务器将该调用请求转发给目标API所在的目标业务服务器，可以包括：网关服务器按照所获得的地址信息，将该调用请求转发给目标API所在的目标业务服务器。
上述目标API的地址信息可以包括目标API所在业务服务器(即目标业务服务器)的IP地址(Internet Protocol Address，互联网协议地址/网际协议地址)和/或MAC(Media Access Control，媒体访问控制)地址，以及目标API在目标业务服务器中的接口地址，但并不限于此。上述调用目标API的操作类型可以包括常见的POST操作和GET操作等；调用目标API的所需资源类型，示例性的，在调用API进行关闭云主机的操作的情况下，所需资源类型为云主机；在调用API进行关闭数据库的操作的情况下，所需资源类型为数据库；在调用API进行网络带宽的升级的情况下，所需资源类型为带宽。
需要说明的是，本申请实施例中，目标API的内部服务信息包括了对调用该目标API的调用请求进行合法性认证时所需的信息，并不限于上述调用目标API的操作类型和所需资源类型，本领域技术人员可以根据合法性验证的实际需求设置上述内部服务信息所包括的信息，本申请实施例在此对上述内部服务信息所包含的具体内容不做限定。
另外，网关服务器对于安全性的验证可以表现为以下至少之一，但并不限于此：网关服务器验证该目标API的调用请求是否携带有木马或病毒，如果携带有木马或病毒，则判定该目标API的调用请求不合法；如果未携带木马或病毒，则判定该目标API的调用请求合法。网关服务器验证一定时间内目标API调用设备针对目标API的调用次数是否达到预设阈值，如果达到预设阈值，则判定该目标API的调用请求不合法；如果未达到预设阈值，则判定该目标API的调用请求合法。
针对此种实现方式，可以理解的是，上述调用目标API的预设条件可以包括：上述针对目标API的调用请求通过合法性和安全性的验证。示例性的，网关服务器获得上述针对目标API的调用请求之后，首先获得目标API的内部服务信息，所获得的目标内部服务信息包括目标API的地址信息、调用目标API的操作类型和所需资源类型，然后网关服务器基于调用目标API的操作类型和所需资源类型，对该调用请求进行合法性和安全性的验证，验证通过后，网关服务器按照上述内部服务信息中所携带的地址信息，将调用请求转发给目标API所在的目标业务服务器。
针对目标API的内部服务信息的获得方式，一种情况下，API调用系统中所有API的内部服务信息可以存储在网关服务器本地，当网关服务器接收到针对于目标API的调用请求时，网关服务器首先在本地查找出目标API的内部服务信息。示例性的，网关服务器本地存储有API的标识信息与内部服务信息的对应关系表；网关服务器接收到针对于目标API的调用请求中携带有目标API的标识信息，则网关服务器根据调用请求中所携带的该标识信息查找上述对应关系表，进而找出该标识信息对应的内部服务信息，即目标API的内部服务信息。
可以理解，如果API调用系统中所有API的内部服务信息都存储在网关服 务器本地，内部服务信息将会占用网关服务器的存储空间，并且，网关服务器还需要在本地查找内部服务信息，查找操作可能会消耗网关服务器的CPU(Central Processing Unit，中央处理器)资源。
为了减少对网关服务器存储空间的占用以及CPU的消耗，另一种情况下，如图2所示，上述API调用系统还可以包括用于存储API的内部服务信息的数据库服务器，
上述网关服务器获得目标API的内部服务信息，可以包括：网关服务器向数据库服务器发送针对目标API的内部服务信息的获取请求；接收数据库服务器基于该获取请求回复的目标API的内部服务信息。
上述数据库服务器，可以用于接收网关服务器发送的获取请求；按照该获取请求，从本地获得目标API的内部服务信息，并将目标API的内部服务信息发送给网关服务器。
在本实现方式中，API的内部服务信息被存储在API调用系统中额外配置的数据库服务器中，当网关服务器接收到针对目标API的调用请求时，网关服务器首先生成一个针对目标API的内部服务信息的获取请求，然后将该获取请求发送给数据库服务器，数据库服务器接收到该获取请求之后，在其本地查找目标API的内部服务信息，并将所查找的目标API的内部服务信息发送给网关服务器。
示例性的，数据库服务器内存储有API的标识信息与内部服务信息的对应关系表；网关服务器接收到携带有目标API的标识信息的调用请求时，生成一携带有该标识信息的获取请求，再将该获取请求发送给数据库服务器，数据库服务器接收到该获取请求之后，根据本地存储的关系表，在其本地查找该标识信息对应的内部服务信息，查找到后，将所查找到的服务信息发送给网关服务器，则网关服务器获得目标API的内部服务信息。
本申请实施例并不限定该数据库服务器的种类，例如其可以是常见的redis(一种数据库)数据库服务器。另外，为了保证数据的高可用，API调用系统中可以部署有多个数据库服务器，各个数据库服务器以主从模式存在，即：其中一个处于主状态的数据库服务器处于工作状态，其可以与网关服务 器进行交互；其余的处于从状态的数据库服务器中则存储着与处于主状态的数据库服务器相同的数据，在处于主状态的数据库服务器发生故障时，其中一个处于从状态的数据库服务器切换成为新的处于主状态的数据库服务器，并同网关服务器进行交互。当然，本申请实施例对上述多个数据库服务器在主从模式下的具体工作方式可以可以不做限定。
作为本申请实施例的另一种可选的实现方式，上述网关服务器判断所接收到的调用请求是否满足调用目标API的预设条件，也可以为：基于所接收到的调用请求中携带的签名，对该调用请求进行签名和权限的验证；判断签名和权限的验证是否通过，在判断结果为通过的情况下，判定该调用请求满足调用目标API的预设条件；在判断结果为没有通过的情况下，判定该调用请求不满足调用目标API的预设条件。
需要说明的是，API调用设备发送调用请求前，可以首先获得一个签名，该签名可以通过预设的签名计算方法获得，并且所发送的调用请求中，携带有上述计算获得的签名。当然，本申请实施例对API调用设备获得签名的具体实现方法不进行限定，只要API调用设备能够获取到签名即可。
另外，关于对该调用请求进行签名和权限的验证，即对该调用请求进行AK(Access Key ID)/SK(Secret Access Key)，对于验证的具体实现方式可以采用相关技术中的方式，但并不限于此，只要能够实现对该调用请求进行签名和权限的验证即可，本申请实施例并不做限定。
需要说明的是，网关服务器基于所接收到的调用请求中携带的签名，对该调用请求进行签名和权限的验证，一种情况下，可以是网关服务器自身利用所接收到的调用请求中携带的签名，直接对该调用请求进行签名和权限的验证，即关于该调用请求进行签名和权限的验证全部由网关服务器完成。此情况下，网关服务器可以快速获得签名和权限的验证结果。
但是，上述情况下，网关服务器需要执行签名和权限的验证，势必会消耗网关服务器的CPU等资源；同样为了减少对网关服务器CPU的消耗，另一种情况下，在图1或者图2所示系统实施例的基础上，如图3所示，API调用系统还可以包括用于验证签名和权限的验证服务器，
上述网关服务器基于所接收到的调用请求中携带的签名，对该调用请求进行签名和权限的验证，可以表现为：网关服务器向验证服务器发送携带有该调用请求所携带签名的签名和权限验证请求；网关服务器接收验证服务器针对签名和权限验证请求反馈的验证结果。
相应的，上述验证服务器，可以用于接收网关服务器发送的签名和权限验证请求；根据该签名和权限验证请求中携带的签名，对上述调用请求进行签名和权限的验证，得到验证结果；将所得到的验证结果发送给网关服务器。
可以理解，在此情况下，网关服务器接收到上述针对于目标API的调用请求后，生成一个签名和权限验证请求，该签名和权限验证请求携带有该调用请求中所携带的签名；然后网关服务器将所生成的签名和权限验证请求发送给验证服务器。验证服务器接收到该签名和权限验证请求后，根据签名和权限验证请求中所携带的签名，对上述调用请求进行签名和权限的验证，得到验证结果，最后将所得到的验证结果发送给网关服务器。
针对此种实现方式，可以理解的是，上述调用目标API的预设条件可以为：上述针对目标API的调用请求通过签名和权限的验证。示例性的，网关服务器获得上述针对目标API的调用请求之后，首先从该调用请求中提取签名，然后生成携带该签名的签名和权限认证请求，而后网关服务器将签名和权限认证请求发送给验证服务器。验证服务器根据签名和权限认证请求所携带的签名，对调用请求进行签名和权限的认证，获得验证结果为验证通过，然后将验证结果发送给网关服务器。网关服务器接收到的验证结果为验证通过，网关服务器将调用请求转发给目标API所在的目标业务服务器。
本申请实施例中，一种实现方式下，上述调用目标API的预设条件可以为：针对目标API的调用请求通过合法性和安全性的验证；另一种实现方式下，上述调用目标API的预设条件也可以为：针对目标API的调用请求通过签名和权限的验证。在实际应用中，上述两种实现方式可以结合在一起使用，即，调用目标API的预设条件包括：针对目标API的调用请求通过合法性、安全性以及签名和权限的验证；而在此情况下，验证合法性、验证安全性以及验证签名和权限的具体执行顺序可以是任意的，本申请实施例在此不做限定。
另外上述两种实现方式并不构成对本申请的限定，实际应用中，本领域 技术人员完全可以设置其他具体的调用目标API的预设条件，本申请实施例在此不再赘述。
本申请实施例提供的API调用系统中的目标业务服务器，用于接收网关服务器转发的上述调用请求；并处理该调用请求，获得调用结果；将所获得的调用结果发送给网关服务器。
在本申请实施例中，目标业务服务器在接收到网关服务器发送的调用请求时，不需要对该调用请求做任何的验证，直接处理该调用请求，获得调用结果，并将该调用结果发送给网关服务器，以使得网关服务器将该调用结果反馈给目标API调用设备。当然，目标业务服务器处理该调用请求，获得调用结果的具体实现方式可以不做限定，即其可以是相关技术中的实现方式，也可以不是。
下面针对本申请实施例的有益技术效果进行简单说明。
在相关技术中，对于部署有API的、同属于一个运营商的多个业务服务器而言，每个业务服务器在接收到API调用设备发送的调用请求时，都需要首先判断该调用请求是否满足调用条件，只有在满足调用条件的情况下，才会处理该调用请求，并获得调用结果。所以，为满足业务服务器具备判断调用请求是否满足调用条件的能力，每个业务服务器中都必须要提供额外的资源以实现上述能力，造成了业务服务器资源的浪费。
但是，实际应用中，同属于一个运营商的多个业务服务器都需要进行逻辑相同的判断调用请求是否满足调用条件的操作，例如，每个业务服务器在接收到API调用设备的调用请求时，都可以验证调用请求的合法性和安全性。所以本申请为了解决上述资源浪费的问题，通过网关服务器为每个业务服务器完成判断调用请求是否满足调用条件的操作。
可以理解，相关技术中，每个业务服务器中都需要消耗额外的资源来提供判断调用请求是否满足调用条件的能力，而本申请实施例中，仅需要利用网关服务器来提供判断调用请求是否满足调用条件的能力，可以避免每个业务服务器为实现判断调用请求是否满足调用条件的能力，均需要提供额外的资源而造成的资源浪费问题。
另外，相关技术中，为了保证每个业务服务器都可以良好稳定地提供判断调用请求是否满足调用条件的能力，针对每个业务服务器都需要投入维护和开发成本来保证上述能力；而本申请实施例提供的方案中，仅需要在网关服务器中投入维护和开发成本，以保证网关服务器具有判断调用请求是否满足调用条件的能力；并且，相关技术中，工作人员在开发API的过程中，还需要同时在业务服务器中进行关于上述能力的开发工作，而本申请实施例提供的方案中，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的直接开发，所以本申请实施例提供的方案的维护和开发成本低。
由以上可知，与相关技术相比，本实施例提供的方案中，判断调用请求是否满足调用条件的任务全部由网关服务器完成，API调用系统中的业务服务器不需要执行判断调用请求是否满足调用条件的任务，避免了每个业务服务器均需要为执行该任务而提供额外的资源所造成的资源浪费问题。另外，本实施例提供的方案也可以避免工作人员在开发API的过程中，在业务服务器中进行关于上述任务所对应判断能力的开发工作，即，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的开发，所以本实施例提供的方案中针对业务服务器中API的维护和开发成本低。
需要说明的是，本申请实施例中，为了保证API调用系统的可用性，上述API调用系统中可以存在有至少两个网关服务器，而此处的至少两个网关服务器可以是以主从模式存在的，即：其中一个处于主状态的网关服务器用于在实际工作中同API调用设备、业务服务器等进行交互；其余的处于从状态的网关服务器中则存储着与处于主状态的网关服务器相同的数据，并且不与API调用设备、业务服务器等进行交互，在处于主状态的网关服务器发生故障时，其中一个处于从状态的网关服务器切换成为新的处于主状态的网关服务器，并同上述API调用设备、业务服务器等进行交互。当然，上述至少两个网关服务器在主从模式下的具体工作方式可以是相关技术的方案，也可以不是，本申请实施例对此并不做限定。
上述至少两个网关服务器可以是以主从模式存在的，但是此情况下，API调用系统中的可用的网关服务器始终只有一个，对于系统所具备的判断调用 请求是否满足调用条件的能力并没有提升。所以本申请实施例中，上述至少两个网关服务器可以是多活的模式存在的，上述至少两个网关服务器中每个网关服务器具有相同的功能。
此情况下，API调用系统还可以包括有一个对应于上述两个网关的负载均衡器，目标API调用设备发送调用请求时，首先将调用请求发送给该负载均衡器，由该负载均衡器从上述至少两个网关服务器中选择一个网关服务器，然后将调用请求发送给所选择的网关服务器，进而由所选择的管理服务器执行操作：接收目标API调用设备发送的上述调用请求；判断该调用请求是否满足调用目标API的预设条件；如果是，将该调用请求转发给目标API所在的目标业务服务器；接收目标业务服务器发送的调用结果，并将调用结果反馈给目标API调用设备。
此外，本申请实施例中，为了保证网关服务器具有高性能，网关服务器可以是一种基于openresty实现的插件式网关。其中，openresty是一种基于nginx(高性能的HTTP(HyperText Transfer Protocol，超文本传输协议)和反向代理服务器)与Lua(一种轻量小巧的脚本语言)的高性能Web(World Wide Web，万维网)平台，其内部集成了大量精良的Lua库、第三方模块以及大多数的依赖项，以方便搭建能够处理超高并发、扩展性极高的动态Web应用、Web服务和动态网关。openresty通过汇聚各种设计精良的nginx模块，从而将其有效地变成一个强大的通用Web应用平台。
其中，lua是一种弱类型语言，其开发效率相较于java和golang等强类型语言有更高的开发效率，能够保证网关服务器的开发和维护成本低。
openresty的目标是让Web服务直接跑在nginx服务内部，充分利用nginx的非阻塞I/O(Input/Output)模型，不仅仅对HTTP客户端请求，甚至于对远程后端诸如MySQL(一种数据库管理系统)、PostgreSQL(一种数据库管理系统)、Memcached(一种高性能的分布式内存对象缓存系统)以及Redis(一种数据库)等都进行一致的高性能响应。
因而，在本申请实施例中，Web开发人员和系统工程师可以使用Lua脚本语言调动nginx支持的各种C(一种通用计算机编程语言)语言模块以及Lua模块，快速构造出足以胜任10K乃至1000K以上单机并发连接的高性能的网关服 务器。
本申请实施例中，基于openresty实现的网关服务器具有非常高的性能，其组织结构如图4所示。网关服务器中的nginx基于epoll(字符设备驱动中的一种函数)实现，使得面对大的并发量的时候，网关服务器仍然维持着较小的资源占用量。网关服务器处理任意请求时，充分利用了I/O复用的实现技巧，使得其内进程数目大大的降低，另外，其中的nginx的worker进程和lua-vm(一种虚拟机)融合在一起，共享一个进程资源，当请求达到worker进程后，通过lua的coroutine(协程)能够快速的创建对应该请求的独立的‘栈’资源，保证数据的安全和有效。并且corotine的创建和销毁代价大大低于普通的线程和进程的创建和销毁。
在本申请实施例中，lua-vm内存以及nginx-worker(子进程)的共享内存(shm)中都可以缓存API的内部服务信息，例如，在网关服务器获得目标API的内部服务信息时，lua-vm内存以及nginx-worker的共享内存将所获得的内部服务信息缓存1分钟，以使得此后的1分钟内，网关服务器再次接收到针对于目标API的调用请求时，可以直接从本地的lua-vm内存以及nginx-worker的共享内存中获得目标API的内部服务信息，所以本申请实施例对于目标API的内部服务信息的获取效率非常高。
当然，在本申请实施例中，可以设置网关服务器获取目标API的内部服务信息的优先级为：lua-vm内存、nginx-worker的共享内存、数据库服务器。即，网关服务器首先从lua-vm内存获取目标API的内部服务信息，如果获取不到，再从nginx-worker的共享内存中获取目标API的内部服务信息，如果获取不到，再从数据库服务器中获取目标API的内部服务信息。
具体的，参照图4，在上述网关服务器的内部，任意一个待处理的请求，如上述调用请求或验证请求等，首先被nginx-master(主进程)获得，nginx-master针对上述待处理的请求进行处理TCP(Transmission Control Protocol，传输控制协议)通用接收逻辑的处理后，首先将socket(套接字)句柄发送给由nginx-master启动常驻存在的nginx-worker(工作者)，然后利用该socket句柄将上述请求发送给nginx-worker。
nginx-worker接收到上述请求后，将该请求转发给在其后启动的与其一一 对应的lua-vm。lua-vm接收到nginx-worker发送的上述请求(request)后，首先创建一个协程(lua-coroutine)，由该协程处理上述请求，例如向验证服务器发送签名和权限验证请求、将调用请求转发给目标业务服务器等。
其中，该nginx-master(为nginx中的master进程，即主进程，也可以称为管理进程)在nginx中用于管理nginx-worker，该nginx-worker(为nginx中的worker进程，即子进程，也可以称为工作进程)在nginx中用于处理基本网络事件，该nginx-master和nginx-worker均是以进程的形式存在。其中，lua-vm可以指一种基于lua的虚拟机。
本申请实施例中，在上述API调用系统中包含有数据库服务器情况下，在图2所示系统实施例的基础上，上述API调用系统还可以包括业务开发设备以及管理服务器。如图5所示，API调用系统中包括：网关服务器、目标API调用设备、API调用设备1～m、目标业务服务器、业务服务器1～n、数据库服务器、管理服务器、目标业务开发设备以及业务开发设备1～x。
其中，m、n和x均为大于或等于0的整数。
此情况下，对应于目标API的目标业务开发设备，可以用于向管理服务器发送针对目标API的管理指令。
可以理解，上述业务开发设备可以是负责开发业务服务器中的API的开发人员所使用的设备。上述目标业务开发设备中可以设置有用户输入界面，开发人员可以在用户输入界面输入指令信息，然后由业务开发设备生成具体的管理指令。
此处的管理指令可以是针对目标API的上线指令、下线指令、修改指令或删除指令中的任意一种。
上述管理服务器，可以用于接收目标业务开发设备发送的管理指令；验证所接收的管理指令是否合法，如果合法，将该管理指令转发给数据库服务器；
此处的验证管理指令是否合法，可以是验证管理指令所对应的用户是否具有相应的管理权限，其用户名和密码是否正确，以及其访问流量是否达到上限值中的至少一种。当然，关于该管理指令是否合法的验证可以使用相关 技术中的方案，也可以不是，本申请实施例并不做限定。
需要说明的是，本申请实施例中，API调用系统中可以具有至少两个管理服务器，每个管理服务器具有相同的功能，此情况下，API调用系统还可以包括有一个对应于上述至少两个管理服务器的负载均衡器，目标API调用设备发送管理指令时，首先将管理指令发送给该负载均衡器，由该负载均衡器从上述至少两个管理服务器中选择一个管理服务器，然后将管理指令发送给所选择的管理服务器，进而由所选择的管理服务器执行操作：验证所接收的管理指令是否合法，在验证结果为合法的情况下，将管理指令转发给数据库服务器。
上述数据库服务器，还可以用于接收管理服务器转发的管理指令，并按照该管理指令，更新本地存储的API的内部服务信息。
数据库服务器按照该管理指令，更新本地存储的API的内部服务信息，可以理解为：以数据库服务器本地存储的API的内部服务信息作为一个整体，数据库服务器按照该管理指令执行操作后所得到的本地存储的API的内部服务信息，不同于执行操作前本地存储的API的内部服务信息。在本申请实施例中：
当该管理指令为针对目标API的上线指令时，该管理指令中携带有目标API的内部服务信息，而数据库服务器本地则没有关于目标API的内部服务信息的记录，所以数据库服务器需要将管理指令所携带的目标API的内部服务信息记录到本地。故此情况下，数据库服务器更新本地存储的API的内部服务信息可以理解为：数据库服务器在其本地新增一个目标API的内部服务信息。
当该管理指令为针对目标API的下线或者删除指令时，数据库服务器本地已经存在关于目标API的内部服务信息的记录，所以数据库服务器需要按照管理指令，将目标API的内部服务信息从本地删除。故此情况下，数据库服务器更新本地存储的API的内部服务信息可以理解为：数据库服务器从其本地删除目标API的内部服务信息。
当该管理指令为针对目标API的修改指令时，该管理指令中携带有修改后的目标API的内部服务信息，数据库服务器本地记录有关于目标API的内部服务信息的记录，所以数据库服务器需要将本地所记录的目标API的内部服务信 息，替换为管理指令所携带的目标API的内部服务信息。故此情况下，数据库服务器更新本地存储的API的内部服务信息可以理解为：将本地所记录的目标API的内部服务信息，替换为管理指令所携带的目标API的内部服务信息。
在本申请实施例中，管理服务器本地同样可以存储有API调用系统中各个API的内部服务信息，所以上述管理服务器在验证所接收的管理指令合法的情况下，如果管理指令是上线指令、下线指令、修改指令中的任意一种，管理服务器可以按照管理指令，更新本地存储的API的内部服务信息，具体的更新方式可以参照数据库服务器更新本地存储的API的内部服务信息所采用的实现方式，本申请实施例在此不再详细介绍。
需要说明的是，当该管理指令是删除指令时，管理服务器不需要删除其本地记录的关于目标API的内部服务信息，即仅需要数据库服务器按照管理指令，删除数据库服务器本地记录的目标API的内部服务信息。另外，在管理服务器中存储有API调用系统中各个API的内部服务信息的情况下，该管理指令还可以是针对于目标API的注册指令，当数据库服务器判断该注册指令合法时，仅需要将注册指令中所携带的目标API的内部服务信息新增到其本地，不需要将该注册指令发送给数据库服务器。
示例性的，参照图6，当上述管理指令为上线指令、下线指令、修改指令中的任意一种时，目标业务开发设备下发管理指令的方式如下：目标业务开发设备获得针对目标API的管理指令，并将该管理指令发送给管理服务器。管理服务器接收到该管理指令后，首先验证该管理指令是否合法，如果合法，基于该管理指令中所携带的目标API的内部服务信息，更新本地存储的API的内部服务信息；并将该管理指令发送给数据库服务器，并向目标业务开发设备发送管理指令的下发结果，即告知目标业务开发设备已成功下发管理指令。而数据库服务器接收到该管理指令后，直接基于该管理指令中所携带的目标API的内部服务信息，更新本地存储的API的内部服务信息。
例如，开发人员需要上线目标API，则开发人员在目标业务开发设备中输入目标API的内部服务信息，然后目标业务开发设备生成针对目标API的上线指令，并将该上线指令发送给管理服务器，管理服务器验证该上线指令为合法的，则管理服务器将上线指令中所携带的目标API的内部服务信息增加到其 本地，并将该上线指令发送给数据库服务器，数据库服务器则同样将上线指令中所携带的目标API的内部服务信息记录到其本地，完成目标API的上线操作。可以理解，在此后，目标API调用设备调用目标API时，网关服务器可以从数据库服务器中获得目标API的内部服务信息。
再如，开发人员需要下线目标API，则开发人员在目标业务开发设备中输入下线目标API的指令信息，然后目标业务开发设备基于该指令信息，生成针对目标API的下线指令，并将该下线指令发送给管理服务器，管理服务器验证该下线指令为合法的，则管理服务器将本地记录的目标API的内部服务信息删除，并将该下线指令发送给数据库服务器，数据库服务器则同样将其本地记录的目标API的内部服务信息删除，完成目标API的下线操作。可以理解，在此后，目标API调用设备再次调用目标API时，网关服务器不可以从数据库服务器中获得目标API的内部服务信息，目标API调用设备无法调用目标API。
当管理服务器存储有API调用系统中各个API的内部服务信息时，可以设置网关服务器获取目标API的内部服务信息的优先级为：lua-vm内存、nginx-worker的共享内存、数据库服务器以及管理服务器中所记录的各个API的内部服务信息时。
另外，本申请实施例中，该管理服务器还可以为各个业务开发设备提供注册服务、修改服务、启动服务、停止服务以及注销服务的功能。在API调用系统中，服务是由各个业务服务器所提供的，例如云主机服务；在本申请实施例中，注册服务可以理解为：将服务所对应的业务服务器的地址信息存储在管理服务器中；修改服务可以理解为：修改存储在管理服务器以及数据库服务器中的服务所对应业务服务器的地址信息；启动服务可以理解为：设置服务所对应业务服务器的状态为可访问状态；停止服务可以理解为：设置服务所对应业务服务器的状态为不可访问状态，但不删除服务所对应业务服务器的地址信息；注销服务可以理解为：删除服务所对应业务服务器的地址信息。
综上，本申请实施例中，API调用系统中新接入即上线一个API时，开发人员针对新接入的API，不需要在该API所在的业务服务器上开发判断调用请求是否满足调用条件的功能，可以直接基于网关服务器实现此功能，大大降 低API调用系统中API的接入成本，同时由于减少了开发上述功能的过程，所以本申请实施例的方案还可以保证API的快速接入。
另外，本申请实施例的方案可以通过管理服务器实现目标API的上线、下线、修改、注册和删除的功能，还能够实现注册服务、修改服务、启动服务、停止服务以及注销服务的功能。这些功能由管理服务器集成实现，可以便于在API调用系统中设置严格的系统状态方程，保证系统在实现上述功能的过程中，不会因为异常的操作出现数据的异常。
需要说明的是，本申请实施例中的管理服务器是基于silm(一种PHP(Hypertext Preprocessor，超文本预处理器)微框架)+notorm(一种轻量级orm(Object Relational Mapping，对象关系映射)框架)实现的。上述silm+notorm是一套经典的组件，在保证高效的执行效率的同时，大大降低了开发的成本，一定程度上保证了开发的有效性。相较于相关技术中上述功能由各业务服务器分别实现的方案，本申请实施例中将上述功能集中在管理服务器中实现的方案具有更高的稳定性，在环境部署上也更加统一。而且，对于开发人员来说，其可以通过管理服务器方便的控制和管理自身的服务和API。本申请实施例中，在上述任一系统实施例的基础上，上述API调用系统还可以包括日志服务器；以图7为例，如图7所示，在图1所示方法实施例的基础上，上述API调用系统还可以包括日志服务器。
相应的，上述网关服务器，还可以用于在接收目标业务服务器发送的调用结果之后，针对目标API的调用过程，生成目标日志；将所生成的目标日志发送给日志服务器。
上述日志服务器，可以用于接收网关服务器发送的目标日志，并将目标日志记录在本地。
网关服务器生成目标日志的方式可以是相关技术所采用的方式，也可以不是，本申请实施例并不做限定。可以理解的是，对于API调用系统而言，其所有的API调用过程都由网关服务器对应生成日志，网关服务器针对各个调用过程生成统一的日志，大大降低了API调用系统中针对各个API调用过程所生成的日志的异构率，这对于通过日志进行的数据挖掘有重要的意义；例如，在API调用系统中还包括有管理服务器和业务开发设备的情况下，业务开发设 备可以通过管理服务器调取日志服务器中所存储的日志信息，以供开发人员查看。
本申请实施例中还可以基于logstash(一种接收，处理，转发日志的工具)+日志服务器+elasticsearch(一种搜索程序)+rabbitmq(一种消息队列)的模式实现日志的收集和处理；该模式能准实时的收集Kop系统产生的数据，并且通过elasticsearch能快速、自由的提供简单分析能力。
其中，logstash可以部署在网关服务器中，并且API调用系统中的rabbitmq可以部署在不同的多个机器上，rabbitmq下对应设置有多个exchange(一种消息转发模块)，exchange采用了replicat(一种进程)的部署方式，exchange采用多台机器部署。另外，elasticsearch可以布置在多个机器上，同样elasticsearch采用replicat+sharding(分片)的部署方式，以保证数据的可用性。
logstash离线地结构化网关服务器所产生的目标日志，将目标日志转化成json(JavaScript Object Notation，JS对象标记)格式；然后logstash利用durable模式(一种为了防止宕机等异常而导致消息无法及时接收设计的模式)从rabbitmq的各个exchange中选择一个exchange，将json格式下的目标日志传递到所选择的exchange下。
所选择的exchange针对elasticsearch和日志服务器分别建立两个queue(队列)；queue同样使用durable的模式，以确保未消费的数据的可用性。可以理解，针对同一条日志信息，exchange将该日志信息同时放置在两个queue中，elasticsearch可以消费其中一个queue中的该日志信息，而日志服务器可以消费另一个queue中的该日志信息。
其中，该消费可以理解为使用。
本申请实施例中，elasticsearch可以消费其中一个queue中的日志信息，进而准实时的获取日志信息。同时，elasticsearch可以存储近一段时间内所获取的日志信息，并每间隔一定时间为新获取的日志信息构建一个索引，例如，elasticsearch可以存储近30天内所获取的日志信息，并每间隔1天为新获取的日志信息构建一个索引。
日志服务器可以消费另一个queue中的日志信息，进而将所获取的日志信 息进行永久的保存。
下面，参照图8，通过一个可选实例来对本申请进行简单介绍。
如图8所示，API调用系统中的目标API调用设备针对目标API的调用过程如下：目标API调用设备首先按照预设的签名计算方法计算签名，然后生成携带有该签名的、针对于目标API的调用请求，并将所生成的调用请求发送给网关服务器。
网关服务器接收到目标API调用设备发送的针对于目标API的调用请求后，首先生成针对目标API内部服务信息的获取请求，该获取请求中携带有目标API的标识信息；然后将该获取请求发送给数据库服务器。
数据库服务器中存储有API调用系统中各个API的内部服务信息，即记录有每个API的标识信息与其内部服务信息的对应关系表。当数据库服务器接收到上述获取请求时，利用该获取请求中携带的目标API的标识信息，从本地记录的对应关系表中获得目标API的内部服务信息；并将目标API的内部服务信息发送给网关服务器；其中，该目标API的内部服务信息包括目标API的地址信息，调用目标API的操作类型以及所需资源类型。
网关服务器接收到数据库服务器发送的目标API的内部服务信息后，基于调用目标API的操作类型以及所需资源类型，对上述调用请求进行合法性验证，在合法性验证通过的情况下，再对上述调用请求进行安全性验证，在安全性验证通过的情况下，生成针对该调用请求的签名和权限认证请求，并将所生成的签名和权限认证请求发送给验证服务器。
验证服务器接收到该签名和权限认证请求后，对上述调用请求进行签名和权限的认证，得到验证通过的验证结果，并将此验证结果发送给网关服务器。
网关服务器接收到该验证结果后，按照目标API的地址信息，将上述调用请求转发给目标业务服务器。目标业务服务器接收到网关服务器转发的调用请求后，直接处理该调用请求，获得调用结果，并将该调用结果发送给网关服务器。
网关服务器接收到上述调用结果后，一方面，针对上述目标API的调用过程，生成目标日志，并可将该目标日志发送给日志服务器(图8中未示出)，日志服务器接收到该目标日志后，将目标日志存储在其本地。另外，网关服务器，还将所接收到的调用结果反馈给目标API调用设备，完成目标API的调用。
相应于图1所示系统实施例，本申请实施例提供了一种API调用方法，应用于网关服务器。
如图9所示，本申请实施例提供的API调用方法包括：
S101：接收目标API调用设备发送的针对于目标API的调用请求。
S102：判断所接收到的调用请求是否满足调用该目标API的预设条件。
在步骤S102的判断结果为是的情况下，执行步骤S103：将该调用请求转发给目标API所在的目标业务服务器。
S104：接收目标业务服务器发送的调用结果，并将该调用结果反馈给目标API调用设备，其中，该调用结果为目标业务服务器处理该调用请求所获得的。
其中，本申请实施例中，该网关服务器设置于API调用系统中，该API调用系统还可以包括API调用设备和设置有API的业务服务器。
作为本申请实施例的一种实现方式，如图10所示，上述判断所接收到的调用请求是否满足调用该目标API的预设条件(S102)的步骤，可以包括：
S1021：获得目标API的内部服务信息，其中，所获得的内部服务信息包括目标API的地址信息、调用目标API的操作类型和所需资源类型；
S1022：基于调用目标API的操作类型和所需资源类型，对调用请求进行合法性和安全性的验证；
S1023：判断合法性和安全性的验证是否通过，在判断结果为通过的情况下，判定所接收到的调用请求满足调用目标API的预设条件；在判断结果为没 有通过的情况下，判定所接收到的调用请求不满足调用目标API的预设条件；
上述将该调用请求转发给目标API所在的目标业务服务器(S103)的步骤，可以包括：
按照所获得的地址信息，将该调用请求转发给目标API所在的目标业务服务器。
作为本申请实施例的一种实现方式，相应于图2所示系统实施例，上述API调用系统还可以包括用于存储API的内部服务信息的数据库服务器，
上述获得目标API的内部服务信息(S1021)的步骤，可以包括下述步骤a和步骤b：
步骤a：向数据库服务器发送针对目标API的内部服务信息的获取请求；其中，数据库服务存储有API的内部服务信息；
步骤b：接收数据库服务器基于该获取请求回复的目标API的内部服务信息。
作为本申请实施例的另一种实现方式，如图11所示，上述判断所接收到的调用请求是否满足调用该目标API的预设条件(S102)的步骤，可以包括：
S1024：基于所接收到的调用请求中携带的签名，对该调用请求进行签名和权限的验证；
S1025：判断签名和权限的验证是否通过，在判断结果为通过的情况下，判定该调用请求满足调用目标API的预设条件，在判断结果为没有通过的情况下，判定该调用请求不满足调用目标API的预设条件。
作为本申请实施例的一种实现方式，相应于图3所示系统实施例，上述API调用系统还可以包括用于验证签名和权限的验证服务器，
上述基于所接收到的调用请求中携带的签名，对该调用请求进行签名和权限的验证(S1024)的步骤，可以包括下述步骤A和B：
步骤A：向验证服务器发送携带有该调用请求所携带签名的签名和权限验证请求；
步骤B：接收验证服务器针对该签名和权限验证请求反馈的验证结果。
作为本申请实施例的一种实现方式，相应于图7所示系统实施例，上述API调用系统还可以包括日志服务器；
如图12所示，在上述接收目标业务服务器发送的调用结果的步骤之后，上述方法还可以包括：
S105：针对目标API的调用过程，生成目标日志；
S106：将所生成的目标日志发送给日志服务器，以使得日志服务器将该目标日志记录在本地。
由以上可知，与相关技术相比，本实施例提供的方案中，判断调用请求是否满足调用条件的任务全部由网关服务器完成，API调用系统中的业务服务器不需要执行判断调用请求是否满足调用条件的任务，避免了每个业务服务器均需要为执行该任务而提供额外的资源所造成的资源浪费问题。另外，本实施例提供的方案也可以避免工作人员在开发API的过程中，在业务服务器中进行关于上述任务所对应判断能力的开发工作，即，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的开发，所以本实施例提供的方案中针对业务服务器中API的维护和开发成本低。
相应于图1所示系统实施例，如图13所示，本申请实施例还提供了一种API调用装置，应用于网关服务器，上述装置包括：
接收模块110，用于接收目标API调用设备发送的针对于目标API的调用请求；
判断模块120，用于判断该调用请求是否满足调用目标API的预设条件；
转发模块130，用于在判断模块120的判断结果为是的情况下，将上述调用请求转发给目标API所在的目标业务服务器；
反馈模块140，用于接收目标业务服务器发送的调用结果，并将该调用结果反馈给目标API调用设备，其中，该调用结果为目标业务服务器处理上述调 用请求所获得的。
其中，本申请实施例中，该网关服务器设置于API调用系统中，该API调用系统还可以包括API调用设备和设置有API的业务服务器。
作为本申请实施例的一种可选的实现方式，如图14所示，上述判断模块120，可以包括：
获得单元1201，用于获得目标API的内部服务信息，该内部服务信息包括目标API的地址信息、调用目标API的操作类型和所需资源类型；
第一验证单元1202，用于基于调用目标API的操作类型和所需资源类型，对上述调用请求进行合法性和安全性的验证；
第一判断单元1203，用于判断合法性和安全性的验证是否通过，在判断结果为通过的情况下，判定该调用请求满足调用目标API的预设条件；在判断结果为没有通过的情况下，判定该调用请求不满足调用目标API的预设条件；
相应的，上述转发模块130，可以用于：在判断单元1203的判断结果为是的情况下，按照上述地址信息，将调用请求转发给目标API所在的目标业务服务器。
相应于图2所示系统实施例，上述API调用系统还可以包括用于存储API的内部服务信息的数据库服务器，
相应的，上述获得单元1201，可以包括：
第一发送子单元，用于向数据库服务器发送针对目标API的内部服务信息的获取请求；其中，所述数据库服务器中存储有API的内部服务信息；
第一接收子单元，用于接收数据库服务器基于上述获取请求回复的目标API的内部服务信息。
作为本申请实施例的另一种可选的实现方式，如图15所示，上述判断模块120，可以包括：
第二验证单元1204，用于基于上述调用请求中携带的签名，对该调用请求进行签名和权限的验证；
第二判断单元1205，用于判断签名和权限的验证是否通过，在判断结果为通过的情况下，判定上述调用请求满足调用目标API的预设条件；在判断结果为没有通过的情况下，判定上述调用请求不满足调用目标API的预设条件。
相应于图3所示系统实施例，可选的，上述API调用系统还包括用于验证签名和权限的验证服务器，
上述第二验证单元1204，可以包括：
第二发送子单元，用于向验证服务器发送携带有上述调用请求所携带签名的签名和权限验证请求；
第二接收子单元，用于接收验证服务器针对该签名和权限验证请求反馈的验证结果。
相应于图7所示系统实施例，上述API调用系统还可以包括日志服务器；
相应的，如图16所示，上述装置还可以包括：
生成模块150，用于在接收到目标业务服务器发送的调用结果后，针对目标API的调用过程，生成目标日志；
发送模块160，将所生成的目标日志发送给日志服务器，以使得日志服务器将目标日志记录在本地。
由以上可知，与相关技术相比，本实施例提供的方案中，判断调用请求是否满足调用条件的任务全部由网关服务器完成，API调用系统中的业务服务器不需要执行判断调用请求是否满足调用条件的任务，避免了每个业务服务器均需要为执行该任务而提供额外的资源所造成的资源浪费问题。另外，本实施例提供的方案也可以避免工作人员在开发API的过程中，在业务服务器中进行关于上述任务所对应判断能力的开发工作，即，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的开发，所以本实施例提供的方案中针对业务服务器中API的维护和开发成本低。
本申请实施例还提供了一种电子设备，如图17所示，包括处理器210和存 储器220，其中，存储器220，用于存放计算机程序；处理器210，用于执行存储器220上所存放的程序时，实现图9至图12中任一图所示的API调用方法。
关于该方法各个步骤的具体实现以及相关解释内容可以参见上述图1、2、3、5和7所示的系统实施例，在此不做赘述。
上述电子设备可以具备有实现上述电子设备与其他设备之间通信的通信接口。
上述的处理器210，通信接口，存储器220通过通信总线完成相互间的通信，此处所提到的通信总线可以是外设部件互连标准(Peripheral Component Interconnect，PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。
存储器220可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器210可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
需要说明的是，上述电子设备可以是上述实施例中的网关服务器，但并不限于此。
在本申请提供的又一实施例中，还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述实施例中任一所述的API调用方法。
在本申请提供的再一实施例中，还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述任一API调用方法所述的方 法步骤。
在本申请提供的再一实施例中，还提供了一种计算机程序，当其在计算机上运行时，使得计算机执行上述任一API调用方法所述的方法步骤。
由以上可知，与相关技术相比，本实施例提供的电子设备，计算机可读存储介质，计算机程序产品，计算机程序中，API调用系统中每一个业务服务器都不需要执行判断调用请求是否满足调用条件的任务，避免每个业务服务器均需要为执行该任务而提供额外的资源所造成的资源浪费问题。另外，本实施例提供的方案中，判断调用请求是否满足调用条件的任务全部由网关服务器完成，可以避免工作人员在开发API的过程中，在业务服务器中进行关于上述任务所对应判断能力的开发工作，即，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的开发，所以本实施例提供的方案中针对业务服务器中API的维护和开发成本低。
需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于方法、装置、电子设备以及计算机可读存储介质实施例而言，由于其基本相似于系统实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均 包含在本申请的保护范围内。
工业实用性
基于本申请实施例提供的上述技术方案，API调用系统中每一个业务服务器都不需要执行判断调用请求是否满足调用条件的任务，避免每个业务服务器均需要为执行该任务而提供额外的资源所造成的资源浪费问题。另外，本实施例提供的方案中，判断调用请求是否满足调用条件的任务全部由网关服务器完成，可以避免工作人员在开发API的过程中，在业务服务器中进行关于上述任务所对应判断能力的开发工作，即，判断调用请求是否满足调用条件的任务从业务服务器中被剥离出来，便于工作人员对业务服务器中API的开发，所以本实施例提供的方案中针对业务服务器中API的维护和开发成本低。

Claims (23)

  1. 一种API调用系统，包括：网关服务器、API调用设备以及设置有API的业务服务器，其中，
    所述API调用设备中的目标API调用设备，用于向所述网关服务器发送针对于目标API的调用请求；接收所述网关服务器反馈的针对所述调用请求的调用结果；
    所述网关服务器，用于接收所述目标API调用设备发送的所述调用请求；判断所述调用请求是否满足调用所述目标API的预设条件；如果所述调用请求满足调用所述目标API的预设条件，将所述调用请求转发给所述目标API所在的目标业务服务器；接收所述目标业务服务器发送的调用结果，并将所述调用结果反馈给所述目标API调用设备，其中，所述调用结果为所述目标业务服务器处理所述调用请求所获得的；
    所述目标业务服务器，用于接收所述网关服务器转发的所述调用请求；处理所述调用请求，获得调用结果；将所述调用结果发送给所述网关服务器。
  2. 根据权利要求1所述的系统，其中，所述网关服务器用于：获得所述目标API的内部服务信息，所述内部服务信息包括所述目标API的地址信息、调用所述目标API的操作类型和所需资源类型；基于调用所述目标API的操作类型和所需资源类型，对所述调用请求进行合法性和安全性的验证；判断合法性和安全性的验证是否通过，在判断结果为通过的情况下，判定所述调用请求满足调用所述目标API的预设条件；在判断结果为没有通过的情况下，判定所述调用请求不满足调用所述目标API的预设条件；以及在所述判断结果为通过的情况下，按照所述地址信息，将所述调用请求转发给所述目标API所在的目标业务服务器。
  3. 根据权利要求2所述的系统，其中，所述API调用系统还包括用于存储API的内部服务信息的数据库服务器，
    所述网关服务器，用于向所述数据库服务器发送针对目标API的内部服务信息的获取请求；其中，所述数据库服务存储有API的内部服务信息；接收所述数据库服务器基于所述获取请求回复的所述目标API的内部服务信息；
    所述数据库服务器，用于接收所述网关服务器发送的所述获取请求；按照所述获取请求，从本地获得所述目标API的内部服务信息，并将所述目标API的内部服务信息发送给所述网关服务器。
  4. 根据权利要求3所述的系统，其中，所述API调用系统还包括业务开发设备以及管理服务器；
    对应于所述目标API的目标业务开发设备，用于向所述管理服务器发送针对所述目标API的管理指令；
    所述管理服务器，用于接收所述目标业务开发设备发送的所述管理指令；验证所述管理指令是否合法，在验证结果为合法的情况下，将所述管理指令转发给所述数据库服务器；
    所述数据库服务器，还用于接收所述管理指令，并按照所述管理指令，更新本地存储的API的内部服务信息。
  5. 根据权利要求1所述的系统，其中，所述网关服务器，用于基于所述调用请求中携带的签名，对所述调用请求进行签名和权限的验证；判断签名和权限的验证是否通过，在判断结果为通过的情况下，判定所述调用请求满足调用所述目标API的预设条件；在判断结果为没有通过的情况下，判定所述调用请求不满足调用所述目标API的预设条件。
  6. 根据权利要求5所述的系统，其中，所述API调用系统还包括用于验证签名和权限的验证服务器，
    所述网关服务器，用于向所述验证服务器发送携带有所述调用请求所携带签名的签名和权限验证请求；接收所述验证服务器针对所述签名和权限验证请求反馈的验证结果；
    所述验证服务器，用于接收所述网关服务器发送的所述签名和权限验证请求；根据所述签名和权限验证请求中携带的签名，对所述调用请求进行签名和权限的验证，得到验证结果；将所述验证结果发送给所述网关服务器。
  7. 根据权利要求1～6任一项所述的系统，其中，所述API调用系统还包括日志服务器；
    所述网关服务器，还用于在接收所述目标业务服务器发送的调用结果之后，针对所述目标API的调用过程，生成目标日志；将所生成的目标日志发送给所述日志服务器；
    所述日志服务器，用于接收所述网关服务器发送的所述目标日志，并将所述目标日志记录在本地。
  8. 一种API调用方法，应用于网关服务器，所述方法包括：
    接收目标API调用设备发送的针对于目标API的调用请求；
    判断所述调用请求是否满足调用所述目标API的预设条件；
    如果所述调用请求满足调用所述目标API的预设条件，将所述调用请求转发给所述目标API所在的目标业务服务器；
    接收所述目标业务服务器发送的调用结果，并将所述调用结果反馈给所述目标API调用设备，其中，所述调用结果为所述目标业务服务器处理所述调用请求所获得的。
  9. 根据权利要求8所述的方法，其中，所述判断所述调用请求是否满足调用所述目标API的预设条件的步骤，包括：
    获得所述目标API的内部服务信息，所述内部服务信息包括所述目标API的地址信息、调用所述目标API的操作类型和所需资源类型；基于调用所述目标API的操作类型和所需资源类型，对所述调用请求进行合法性和安全性的验证；判断合法性和安全性的验证是否通过，在判断结果为通过的情况下，判定所述调用请求满足调用所述目标API的预设条件；在判断结果为没有通过的情况下，判定所述调用请求不满足调用所述目标API的预设条件；
    所述将所述调用请求转发给所述目标API所在的目标业务服务器的步骤，包括：按照所述地址信息，将所述调用请求转发给所述目标API所在的目标业务服务器。
  10. 根据权利要求9所述的方法，其中，所述获得所述目标API的内部服务信息的步骤，包括：
    向数据库服务器发送针对目标API的内部服务信息的获取请求；其中，所 述数据库服务存储有API的内部服务信息；
    接收所述数据库服务器基于所述获取请求回复的所述目标API的内部服务信息。
  11. 根据权利要求8所述的方法，其中，所述判断所述调用请求是否满足调用所述目标API的预设条件的步骤，包括：
    基于所述调用请求中携带的签名，对所述调用请求进行签名和权限的验证；
    判断签名和权限的验证是否通过，在判断结果为通过的情况下，判定所述调用请求满足调用所述目标API的预设条件；在判断结果为没有通过的情况下，判定所述调用请求不满足调用所述目标API的预设条件。
  12. 根据权利要求11所述的方法，其中，所述基于所述调用请求中携带的签名，对所述调用请求进行签名和权限的验证的步骤，包括：
    向所述验证服务器发送携带有所述调用请求所携带签名的签名和权限验证请求；
    接收所述验证服务器针对所述签名和权限验证请求反馈的验证结果。
  13. 根据权利要求8～12任一项所述的方法，其中，在所述接收所述目标业务服务器发送的调用结果的步骤之后，所述方法还包括：
    针对所述目标API的调用过程，生成目标日志；
    将所述目标日志发送给日志服务器，以使得所述日志服务器将所述目标日志记录在本地。
  14. 一种API调用装置，应用于网关服务器，所述装置包括：
    接收模块，用于接收目标API调用设备发送的针对于目标API的调用请求；
    判断模块，用于判断所述调用请求是否满足调用所述目标API的预设条件；
    转发模块，用于在所述判断模块的判断结果为是的情况下，将所述调用请求转发给所述目标API所在的目标业务服务器；
    反馈模块，用于接收所述目标业务服务器发送的调用结果，并将所述调用结果反馈给所述目标API调用设备，其中，所述调用结果为所述目标业务服务器处理所述调用请求所获得的。
  15. 根据权利要求14所述的装置，其中，所述判断模块，包括：
    获得单元，用于获得所述目标API的内部服务信息，所述内部服务信息包括所述目标API的地址信息、调用所述目标API的操作类型和所需资源类型；第一验证单元，用于基于调用所述目标API的操作类型和所需资源类型，对所述调用请求进行合法性和安全性的验证；第一判断单元，用于判断合法性和安全性的验证是否通过，在判断结果为通过的情况下，判定所述调用请求满足调用所述目标API的预设条件；在判断结果为没有通过的情况下，判定所述调用请求不满足调用所述目标API的预设条件；
    所述转发模块，用于：在所述判断单元的判断结果为是的情况下，按照所述地址信息，将所述调用请求转发给所述目标API所在的目标业务服务器。
  16. 根据权利要求15所述的装置，其中，所述获得单元，包括：
    第一发送子单元，用于向数据库服务器发送针对目标API的内部服务信息的获取请求；其中，所述数据库服务器中存储有API的内部服务信息；第一接收子单元，用于接收所述数据库服务器基于所述获取请求回复的所述目标API的内部服务信息。
  17. 根据权利要求14所述的装置，其中，所述判断模块，包括：
    第二验证单元，用于基于所述调用请求中携带的签名，对所述调用请求进行签名和权限的验证；
    第二判断单元，用于判断签名和权限的验证是否通过，在判断结果为通过的情况下，判定所述调用请求满足调用所述目标API的预设条件；在判断结果为没有通过的情况下，判定所述调用请求不满足调用所述目标API的预设条件。
  18. 根据权利要求17所述的装置，其中，所述第二验证单元，包括：
    第二发送子单元，用于向所述验证服务器发送携带有所述调用请求所携 带签名的签名和权限验证请求；
    第二接收子单元，用于接收所述验证服务器针对所述签名和权限验证请求反馈的验证结果。
  19. 根据权利要求14～18任一项所述的装置，其中，所述装置还包括：
    生成模块，用于在接收到所述目标业务服务器发送的调用结果后，针对所述目标API的调用过程，生成目标日志；
    发送模块，将所述目标日志发送给日志服务器，以使得所述日志服务器将所述目标日志记录在本地。
  20. 一种电子设备，包括处理器和存储器，其中：
    存储器，用于存放计算机程序；
    处理器，用于执行存储器上所存放的程序时，实现权利要求8-13任一所述的方法步骤。
  21. 一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求8-13任一所述的方法步骤。
  22. 一种计算机程序产品，当其在计算机上运行时，使得计算机执行权利要求8-13任一所述的方法步骤。
  23. 一种计算机程序，当其在计算机上运行时，使得计算机执行权利要求8-13任一所述的方法步骤。
PCT/CN2018/105648 2017-09-14 2018-09-14 Api调用系统、方法、装置、电子设备及存储介质 WO2019052526A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710825481.3A CN109510846B (zh) 2017-09-14 2017-09-14 Api调用系统、方法、装置、电子设备及存储介质
CN201710825481.3 2017-09-14

Publications (1)

Publication Number Publication Date
WO2019052526A1 true WO2019052526A1 (zh) 2019-03-21

Family

ID=65723910

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/105648 WO2019052526A1 (zh) 2017-09-14 2018-09-14 Api调用系统、方法、装置、电子设备及存储介质

Country Status (2)

Country Link
CN (1) CN109510846B (zh)
WO (1) WO2019052526A1 (zh)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110113394A (zh) * 2019-04-19 2019-08-09 浙江数链科技有限公司 Api调用方法和装置
CN110716769A (zh) * 2019-09-27 2020-01-21 武汉极意网络科技有限公司 业务风控网关及业务风控方法
CN110750269A (zh) * 2019-10-25 2020-02-04 浪潮云信息技术有限公司 一种基于步骤驱动的软件实现方法
CN111143087A (zh) * 2019-12-18 2020-05-12 中国平安财产保险股份有限公司 一种接口调用方法、装置、存储介质和服务器
CN111737022A (zh) * 2019-09-30 2020-10-02 北京沃东天骏信息技术有限公司 一种基于微服务的接口调用方法、系统、设备及介质
CN111858083A (zh) * 2019-12-30 2020-10-30 北京嘀嘀无限科技发展有限公司 一种远程服务的调用方法、装置、电子设备及存储介质
CN112256452A (zh) * 2020-10-21 2021-01-22 上海商汤智能科技有限公司 云服务平台的服务项确定方法、装置、设备及存储介质
CN112527413A (zh) * 2020-12-23 2021-03-19 平安普惠企业管理有限公司 一种页面加载方法、装置、设备及存储介质
CN112882688A (zh) * 2021-01-07 2021-06-01 中国人民财产保险股份有限公司 一种基于云的支持多前端项目接入的架构
CN112965901A (zh) * 2021-03-05 2021-06-15 北京百度网讯科技有限公司 Api的测试方法、服务器、系统以及电子设备
CN113114562A (zh) * 2021-03-04 2021-07-13 上海赛可出行科技服务有限公司 一种基于开放平台的参数可配置的网关设计方法
CN113505067A (zh) * 2021-07-09 2021-10-15 浪潮云信息技术股份公司 基于openresty的分布式数据库tpc-c测试优化方法及系统
CN113626064A (zh) * 2021-08-11 2021-11-09 北京奇艺世纪科技有限公司 一种应用程序管理方法及装置
CN114020492A (zh) * 2021-11-09 2022-02-08 中国建设银行股份有限公司 信息处理方法、系统及装置
CN114095576A (zh) * 2021-11-22 2022-02-25 北京爱奇艺科技有限公司 一种调用请求发送方法及装置
CN114172743A (zh) * 2021-12-30 2022-03-11 重庆医药数据信息科技有限公司 一种用于医保终端的安全认证系统和方法
CN114285852A (zh) * 2021-12-28 2022-04-05 杭州数梦工场科技有限公司 基于多级服务平台的服务调用方法及装置
CN114285582A (zh) * 2021-12-22 2022-04-05 中国电信股份有限公司 信息合法性的校验方法及装置、存储介质、电子设备
CN114765552A (zh) * 2021-01-04 2022-07-19 航天信息股份有限公司 数据处理方法、中台系统、存储介质和电子设备
CN115296959A (zh) * 2022-07-25 2022-11-04 紫光云技术有限公司 一种使用Nginx+Lua脚本替代SpringCloudGateway网关的方法
CN115334162A (zh) * 2022-07-26 2022-11-11 国家能源集团江苏电力有限公司 一种基于用户请求的电力服务管理的安全通信方法及系统
CN115842749A (zh) * 2022-11-24 2023-03-24 中电信数智科技有限公司 一种测试环境的切换方法、装置及系统

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110007950A (zh) * 2019-04-10 2019-07-12 优信拍（北京）信息科技有限公司 一种应用程序接口的管理方法、装置及服务器
CN111949286A (zh) * 2019-05-14 2020-11-17 中国移动通信有限公司研究院 一种升级方法、装置、设备及计算机可读存储介质
CN110347501A (zh) * 2019-06-20 2019-10-18 北京大米科技有限公司 一种业务检测方法、装置、存储介质及电子设备
CN110851258B (zh) * 2019-11-08 2024-04-23 深圳前海环融联易信息科技服务有限公司 Api调用方法、装置、计算机设备及存储介质
CN110839087B (zh) * 2020-01-13 2020-06-19 北京懿医云科技有限公司 接口调用方法及装置、电子设备和计算机可读存储介质
CN111416837A (zh) * 2020-02-20 2020-07-14 华迪计算机集团有限公司 政务系统api接口访问网关、方法、电子设备及存储介质
CN111988398A (zh) * 2020-08-19 2020-11-24 政采云有限公司 一种数据获取方法、api网关、介质
CN112181541A (zh) * 2020-09-29 2021-01-05 京东数字科技控股股份有限公司 一种数据处理方法、装置、电子设备及存储介质
CN112583930B (zh) * 2020-12-25 2023-04-18 四川安迪科技实业有限公司 用于多独立系统交互的数据转发同步方法、系统及装置
CN112685201A (zh) * 2020-12-31 2021-04-20 中国建设银行股份有限公司 政务服务接入控制方法和装置
CN112948143B (zh) * 2021-03-04 2024-01-12 北京奇艺世纪科技有限公司 一种应用程序调用方法、装置及调用系统
CN113114765A (zh) * 2021-04-13 2021-07-13 成都九洲电子信息系统股份有限公司 一种基于反向代理的接口调用系统
CN113282602B (zh) * 2021-06-18 2023-10-27 北京奇艺世纪科技有限公司 一种业务请求方法及装置
CN115102784B (zh) * 2022-07-21 2023-06-23 武汉联影医疗科技有限公司 权限信息管理方法、装置、计算机设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103078827A (zh) * 2011-10-25 2013-05-01 腾讯数码（天津）有限公司 第三方应用调用的开放平台系统和实现方法
CN105187372A (zh) * 2015-06-09 2015-12-23 深圳市腾讯计算机系统有限公司 一种基于移动应用入口的数据处理方法、装置和系统
CN106295330A (zh) * 2016-07-29 2017-01-04 努比亚技术有限公司 调用api的控制装置及方法
CN106897586A (zh) * 2016-08-04 2017-06-27 阿里巴巴集团控股有限公司 一种应用程序编程接口api权限管理方法与装置
US20170250853A1 (en) * 2016-02-25 2017-08-31 Open Text Sa Ulc Systems and methods for providing managed services

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1581144A (zh) * 2003-07-31 2005-02-16 上海市电子商务安全证书管理中心有限公司 数字证书本地认证的方法及系统
CN102281311B (zh) * 2010-06-10 2014-06-04 阿里巴巴集团控股有限公司 一种基于开放应用编程接口实现网络业务的方法、系统及装置
CN104717647B (zh) * 2013-12-13 2019-03-22 中国电信股份有限公司 业务能力鉴权方法、设备及系统
US20150188900A1 (en) * 2013-12-31 2015-07-02 Digital River, Inc. Session managment in a multi-tenant, multi-data center environment system and method
US20150229700A1 (en) * 2014-02-12 2015-08-13 Qualcomm Incorporated Protocol translation for media player device control
CN106686021B (zh) * 2015-11-05 2021-06-29 北京京东尚科信息技术有限公司 一种服务调用方法和网关
CN105512279B (zh) * 2015-12-04 2019-05-03 华为技术有限公司 一种元数据访问方法、相关设备及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103078827A (zh) * 2011-10-25 2013-05-01 腾讯数码（天津）有限公司 第三方应用调用的开放平台系统和实现方法
CN105187372A (zh) * 2015-06-09 2015-12-23 深圳市腾讯计算机系统有限公司 一种基于移动应用入口的数据处理方法、装置和系统
US20170250853A1 (en) * 2016-02-25 2017-08-31 Open Text Sa Ulc Systems and methods for providing managed services
CN106295330A (zh) * 2016-07-29 2017-01-04 努比亚技术有限公司 调用api的控制装置及方法
CN106897586A (zh) * 2016-08-04 2017-06-27 阿里巴巴集团控股有限公司 一种应用程序编程接口api权限管理方法与装置

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110113394A (zh) * 2019-04-19 2019-08-09 浙江数链科技有限公司 Api调用方法和装置
CN110716769A (zh) * 2019-09-27 2020-01-21 武汉极意网络科技有限公司 业务风控网关及业务风控方法
CN110716769B (zh) * 2019-09-27 2023-08-04 武汉极意网络科技有限公司 业务风控网关及业务风控方法
CN111737022A (zh) * 2019-09-30 2020-10-02 北京沃东天骏信息技术有限公司 一种基于微服务的接口调用方法、系统、设备及介质
CN111737022B (zh) * 2019-09-30 2024-03-01 北京沃东天骏信息技术有限公司 一种基于微服务的接口调用方法、系统、设备及介质
CN110750269A (zh) * 2019-10-25 2020-02-04 浪潮云信息技术有限公司 一种基于步骤驱动的软件实现方法
CN110750269B (zh) * 2019-10-25 2023-04-21 浪潮云信息技术股份公司 一种基于步骤驱动的软件实现方法
CN111143087B (zh) * 2019-12-18 2024-04-02 中国平安财产保险股份有限公司 一种接口调用方法、装置、存储介质和服务器
CN111143087A (zh) * 2019-12-18 2020-05-12 中国平安财产保险股份有限公司 一种接口调用方法、装置、存储介质和服务器
CN111858083B (zh) * 2019-12-30 2024-05-14 北京嘀嘀无限科技发展有限公司 一种远程服务的调用方法、装置、电子设备及存储介质
CN111858083A (zh) * 2019-12-30 2020-10-30 北京嘀嘀无限科技发展有限公司 一种远程服务的调用方法、装置、电子设备及存储介质
CN112256452A (zh) * 2020-10-21 2021-01-22 上海商汤智能科技有限公司 云服务平台的服务项确定方法、装置、设备及存储介质
CN112527413A (zh) * 2020-12-23 2021-03-19 平安普惠企业管理有限公司 一种页面加载方法、装置、设备及存储介质
CN114765552A (zh) * 2021-01-04 2022-07-19 航天信息股份有限公司 数据处理方法、中台系统、存储介质和电子设备
CN114765552B (zh) * 2021-01-04 2023-11-07 航天信息股份有限公司 数据处理方法、中台系统、存储介质和电子设备
CN112882688A (zh) * 2021-01-07 2021-06-01 中国人民财产保险股份有限公司 一种基于云的支持多前端项目接入的架构
CN113114562A (zh) * 2021-03-04 2021-07-13 上海赛可出行科技服务有限公司 一种基于开放平台的参数可配置的网关设计方法
CN112965901B (zh) * 2021-03-05 2023-08-01 北京百度网讯科技有限公司 Api的测试方法、服务器、系统以及电子设备
CN112965901A (zh) * 2021-03-05 2021-06-15 北京百度网讯科技有限公司 Api的测试方法、服务器、系统以及电子设备
CN113505067A (zh) * 2021-07-09 2021-10-15 浪潮云信息技术股份公司 基于openresty的分布式数据库tpc-c测试优化方法及系统
CN113505067B (zh) * 2021-07-09 2024-02-20 上海沄熹科技有限公司 基于openresty的分布式数据库tpc-c测试优化方法及系统
CN113626064A (zh) * 2021-08-11 2021-11-09 北京奇艺世纪科技有限公司 一种应用程序管理方法及装置
CN114020492A (zh) * 2021-11-09 2022-02-08 中国建设银行股份有限公司 信息处理方法、系统及装置
CN114095576A (zh) * 2021-11-22 2022-02-25 北京爱奇艺科技有限公司 一种调用请求发送方法及装置
CN114095576B (zh) * 2021-11-22 2024-03-08 北京爱奇艺科技有限公司 一种调用请求发送方法及装置
CN114285582B (zh) * 2021-12-22 2024-04-05 中国电信股份有限公司 信息合法性的校验方法及装置、存储介质、电子设备
CN114285582A (zh) * 2021-12-22 2022-04-05 中国电信股份有限公司 信息合法性的校验方法及装置、存储介质、电子设备
CN114285852A (zh) * 2021-12-28 2022-04-05 杭州数梦工场科技有限公司 基于多级服务平台的服务调用方法及装置
CN114285852B (zh) * 2021-12-28 2023-12-26 杭州数梦工场科技有限公司 基于多级服务平台的服务调用方法及装置
CN114172743A (zh) * 2021-12-30 2022-03-11 重庆医药数据信息科技有限公司 一种用于医保终端的安全认证系统和方法
CN115296959A (zh) * 2022-07-25 2022-11-04 紫光云技术有限公司 一种使用Nginx+Lua脚本替代SpringCloudGateway网关的方法
CN115334162B (zh) * 2022-07-26 2023-12-05 国家能源集团江苏电力有限公司 一种基于用户请求的电力服务管理的安全通信方法及系统
CN115334162A (zh) * 2022-07-26 2022-11-11 国家能源集团江苏电力有限公司 一种基于用户请求的电力服务管理的安全通信方法及系统
CN115842749A (zh) * 2022-11-24 2023-03-24 中电信数智科技有限公司 一种测试环境的切换方法、装置及系统

Also Published As

Publication number Publication date
CN109510846A (zh) 2019-03-22
CN109510846B (zh) 2020-11-03

Similar Documents

Publication Publication Date Title
WO2019052526A1 (zh) Api调用系统、方法、装置、电子设备及存储介质
KR102444106B1 (ko) 데이터 웨어하우스로부터 외부 함수를 호출하는 것
CN110191063B (zh) 服务请求的处理方法、装置、设备及存储介质
US10194001B1 (en) Automatic discovery of API information
JP2019067398A (ja) 電子メッセージベースのセキュリティ脅威の自動軽減
US20110302631A1 (en) Systems and methods for logging into an application on a second domain from a first domain in a multi-tenant database system environment
US7881304B2 (en) Using distributed aspects to reorder online application workflows
US11171994B2 (en) Tag-based security policy creation in a distributed computing environment
JP2017509936A (ja) リソースへの繰返しアクセスについてリソースオーナーから認可を要求する要求のバッチ処理の、サードパーティによる実行の容易化
CN111414381B (zh) 数据处理方法、装置、电子设备及存储介质
CN108287894B (zh) 数据处理方法、装置、计算设备及存储介质
WO2016197609A1 (zh) 一种应用的用户信息管理的方法、设备及系统
CN109120614B (zh) 基于分布式系统的业务处理方法及装置
WO2023011274A1 (zh) 一种通讯协议转换方法、设备、系统及网关设备
CN112954050B (zh) 分布式管理方法及装置、管理设备和计算机存储介质
CN112764726A (zh) 一种数据合成的方法和装置
US11700315B2 (en) Software-as-a-service deployment of printing services in a local network
CN103957174A (zh) 语义交换机松耦合系统进行信息处理的方法
AU2018390863B2 (en) Computer system and method for extracting dynamic content from websites
US8640189B1 (en) Communicating results of validation services
CN103957173A (zh) 语义交换机
WO2017032110A1 (zh) 一种应用消息的处理系统、方法及应用设备
CN108347471B (zh) 获取第三方用户信息的方法、装置及系统
CN113497762A (zh) 数据报文的传输方法及装置
US9860326B2 (en) Duplex services residing in a messaging bus

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18856217

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18856217

Country of ref document: EP

Kind code of ref document: A1