Detailed Description
The application is described in further detail below with reference to the drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the application and are not limiting thereof. It should be further noted that, for convenience of description, only some, but not all of the structures related to the present application are shown in the drawings.
Fig. 1 is a flow chart of an application programming interface calling method according to an embodiment of the present application, where the method may be performed by an application programming interface calling device or an electronic device, where the device or the electronic device may be implemented by software and/or hardware, and the device or the electronic device may be integrated into any intelligent device having a network communication function. As shown in fig. 1, the application programming interface calling method may include the steps of:
S101, receiving a request message sent by a third party application through an open platform, wherein the request message at least carries assembled API service information.
The present application allows a third party application to invoke multiple API services, which may be data queries, data processing, or any other service, with one request. The third party application can freely select and combine the required API services according to own business requirements to form a personalized solution without providing a predefined service package by an open platform. The open platform in the application can know the request intention of the third party application in advance, thereby optimizing the internal data processing flow, reducing unnecessary data transmission and processing steps and improving the response speed of the whole request.
S102, extracting the assembled API service information from the request message.
In this step, the request message may be parsed according to a predetermined request message format to obtain a public parameter included in the request message, where the public parameter includes at least an encrypted message, and then the encrypted message is decrypted, and the assembled API service information is extracted from the decrypted message. The predefined request message format of the present application may ensure that all communications follow the same rules and standards, facilitating interoperability between different systems or components. The unified format enables developers to more easily understand and use these interfaces, whether internal services or external APIs.
Optionally, the assembled API service information in the embodiment of the application can also comprise APP ID and signature information.
S103, disassembling the assembled service information into one or more atomic API services.
In this step, all the atomic API services and parameters thereof to be called can be extracted from the request message, an independent request object is generated for each atomic API service, and then the generated atomic API requests are put into a task queue for preparation for sequential or parallel processing.
S104, calling the atomic interfaces corresponding to the atomic API services, and returning the calling results to the third party application.
In a specific embodiment of the present application, one atomic API service corresponds to one atomic interface. For example, atomic API service 1 corresponds to atomic interface 1, atomic API service 2 corresponds to atomic interface 2.
In this step, the atomic interfaces corresponding to the atomic API services may be invoked by the Http/Https proxy node. According to the application, the Http/Https proxy node is used for calling the atomic interfaces corresponding to the atomic API services, and the flexibility and the security of the request can be increased especially when the scenes such as cross-domain request processing, load balancing, caching, security authentication and the like are required to be processed.
The application programming interface calling method provided by the embodiment of the application comprises the steps of receiving a request message sent by a third party application through an open platform, extracting assembled API service information from the request message, disassembling the assembled service information into one or more atomic API services, calling atomic interfaces corresponding to the atomic API services, and returning a calling result to the third party application. That is, in the technical solution of the present application, the third party application may apply for calling a plurality of API services to the open platform at a time, and in a complex service scenario, it is often necessary to integrate data from different sources. Applying for multiple APIs at a time means that all the data needed can be obtained in a single response, reducing coordination work between data sources, making data integration simpler and more straightforward. In the prior art, the current interaction mode of the developer accessing the Open API of the Open platform is to call one service API each time, and when encountering a complex service scenario, the system implementation is complex by calling one API mode once, so that the consumption of the third party application is increased. Compared with the prior art, the application programming interface calling method provided by the embodiment of the application can reduce the complexity of the system and the consumption of third party application under a complex service scene, and the technical scheme of the embodiment of the application is simple and convenient to realize, convenient to popularize and wider in application range.
Fig. 2 is a flowchart of an application programming interface calling method according to another embodiment of the present application. Further optimization and expansion based on the above technical solution can be combined with the above various alternative embodiments. As shown in fig. 2, the application programming interface calling method may include the steps of:
S201, receiving a request message sent by a third party application through an open platform, wherein the request message at least carries assembled API service information.
The request message in the embodiment of the application can comprise common parameters including an encrypted message, an APP ID and signature information, wherein the encrypted message can comprise assembled API service information. The assembled API service information in the embodiment of the present application refers to call information including a plurality of API services in one request, where the API services may be combined together to form a composite request. This approach allows multiple API calls to be completed in one request, thereby improving efficiency, simplifying flow, and reducing the number of network requests. The assembled API service information may be used in complex business scenarios where multiple API services need to work together to complete one business logic.
S202, analyzing the request message according to a predetermined request message format to obtain public parameters contained in the request message, wherein the public parameters comprise an encrypted message, an APP ID and signature information.
And S203, performing authority verification on the third party application according to the APP ID and the signature information.
In this step, authority verification and identity authentication can be performed on the third party application according to the APP ID and signature information. By verifying the APP ID and the signature information, the method and the device can ensure that only legal third-party applications can access the API, and prevent unauthorized applications or malicious attackers from accessing sensitive data. In addition, the signature information can ensure that the request is not tampered in the transmission process, and the integrity and consistency of the data are ensured. In addition, the application can combine the mechanisms of time stamp, random number and the like, and can effectively prevent replay attack, namely, an attacker repeatedly sends the same request.
S204, if the third party application passes the authority verification, the encrypted message is decrypted, and the assembled API service information is extracted from the decrypted message.
The embodiment of the application can decrypt the encrypted message by using the pre-shared key or the public and private key, and extract the assembled API service information from the decrypted message. In one embodiment, decrypting the encrypted message may use the symmetric encryption algorithm AES.
S205, extracting each atomic API service and the assembly sequence of the atomic API service in the assembly service information according to the release record of the open platform.
In a specific embodiment of the present application, the open platform may issue the API in advance, where the API may be an assembled API or a non-assembled API. Specifically, an assembled API refers to a plurality of atomic APIs (i.e., single-function APIs) that are combined together to form a composite service interface. The API design mode allows the client to call a plurality of services through one request, thereby reducing the network round trip times and improving the performance and response speed. While non-assembled APIs refer to single-function APIs, each of which is responsible for accomplishing a particular task. The client needs to call multiple APIs to complete the complex business process.
In one embodiment, it is assumed that three atomic API services are included in the assembled service information, namely atomic API service 1, atomic API service 2, and atomic API service 3, respectively, and that the order of assembly of the three atomic API services is first, second, and third. In this step, the atomic API service 1, the atomic API service 2, and the atomic API service 3, and the order of assembly of the three atomic API services may be extracted from the assembly service information.
The application can combine different atomic API services as required to quickly construct a service flow meeting specific business requirements. This approach supports a high degree of customization and can accommodate a variety of complex business scenarios. Because each atomic API is a separate functional module, the present application can be reused in a plurality of different service flows. Thus, not only code redundancy but also maintenance cost can be reduced.
S206, calling the atomic interfaces corresponding to the atomic API services according to the assembly sequence, and returning the calling result to the third party application.
The application can reduce the round trip times of the network by calling a plurality of API services by one request, thereby obviously improving the performance and response speed of the system, and can also reduce the network delay caused by a plurality of requests, and has more obvious effect especially in a network environment with high delay. In addition, in the micro-service architecture, the assembled API can better coordinate the calling among a plurality of micro-services, and the overall performance and reliability of the system are improved.
The application programming interface calling method provided by the embodiment of the application comprises the steps of receiving a request message sent by a third party application through an open platform, extracting assembled API service information from the request message, disassembling the assembled service information into one or more atomic API services, calling atomic interfaces corresponding to the atomic API services, and returning a calling result to the third party application. That is, in the technical solution of the present application, the third party application may apply for calling a plurality of API services to the open platform at a time, and in a complex service scenario, it is often necessary to integrate data from different sources. Applying for multiple APIs at a time means that all the data needed can be obtained in a single response, reducing coordination work between data sources, making data integration simpler and more straightforward. In the prior art, the current interaction mode of the developer accessing the Open API of the Open platform is to call one service API each time, and when encountering a complex service scenario, the system implementation is complex by calling one API mode once, so that the consumption of the third party application is increased. Compared with the prior art, the application programming interface calling method provided by the embodiment of the application can reduce the complexity of the system and the consumption of third party application under a complex service scene, and the technical scheme of the embodiment of the application is simple and convenient to realize, convenient to popularize and wider in application range.
Fig. 3 is a flowchart illustrating an assembled API service publishing method according to an embodiment of the present application. Further optimization and expansion based on the above technical solution can be combined with the above various alternative embodiments. As shown in fig. 3, the assembled API service publishing method may include the steps of:
S301, acquiring basic information of each API service, and registering the basic information of each API service.
The basic information of the API service in the embodiment of the present application may include a plurality of key fields for describing functions, usage methods, parameters, responses, and the like of the API. The key fields may include, for example, a service ID, an ID that uniquely identifies the API service. Service name: name of API service, for identifying and describing API service. Detailed description of API service, explaining its function and purpose. endpoint-URL path for describing API services. Parameters-input parameters of API service, including parameter name, type, whether it is necessary, etc.
S302, determining whether the registered API service can be assembled into one or more assembled APIs according to the basic information of the registered API service.
In this step, a plurality of atomic API services capable of being assembled into one assembled API may be selected from the registered API services, and then a service scenario label may be selected for the plurality of atomic API services, and the plurality of atomic API services may be assembled into an assembled API corresponding to the service scenario label. The present application can create services with more complex business logic by combining multiple single-function APIs. Such an assembled API can provide more comprehensive and powerful functions than a single API, meeting a wider range of business requirements. The third party application in the application can directly call the packaged assembled API without realizing calling logic of a plurality of APIs from the beginning, thus greatly shortening the development period and accelerating the online time of products.
The application can quickly find the API set suitable for the specific scene through the service scene tag without checking the detailed description of each API one by one, thus greatly improving the discoverability and usability of the APIs. In addition, the business scene label can help a developer understand which APIs can be used together to solve a specific problem or realize a specific function, and the combined use mode can accelerate the development speed of the application and improve the development efficiency.
In one embodiment, determining whether registered API services can be assembled into one or more assembled APIs based on basic information of the registered API services may be performed by 1) retrieving basic information of the registered API services from a database or configuration file, 2) parsing information of each API service to extract necessary fields, and 3) analyzing dependency relationships between the API services to determine the API services that can be assembled together. 4) And determining the calling sequence of the API service according to the dependency relationship and the business logic. 5) One or more assembled APIs are generated based on the analysis results.
S303, if the registered API service can be assembled into one or more assembled APIs, the registered API service is assembled into one or more assembled APIs, and each assembled API is published.
In a specific embodiment of the present application, if the registered API service can be assembled into one or more assembled APIs, the registered API service is assembled into one or more assembled APIs and each assembled API is published, and if the registered API service cannot be assembled into any assembled API, the registered API service is published separately. Each API service is released as a separate unit, which ensures the specificity and clarity of its function. This independence allows each API to be focused on achieving a particular function, easy to understand and use. When API services are independently released, the updating, maintenance, and upgrades of each service do not affect other services. This means that improvements or repair problems can be made for a particular API without causing the overall system to be impacted.
In the embodiment of the application, before the API service is released, the API service can be checked, and if the API check is passed, the operation of releasing the API is executed.
The method for publishing the assembled API service comprises the steps of acquiring basic information of each API service, registering the basic information of each API service, determining whether the registered API service can be assembled into one or more assembled APIs according to the basic information of the registered API service, and if the registered API service can be assembled into one or more assembled APIs, assembling the registered API service into one or more assembled APIs and publishing each assembled API. That is, in the technical scheme of the application, the open platform can assemble a plurality of API services into one assembled API in advance, so that the third party application can directly call the assembled API, thereby reducing the consumption of the third party application and reducing the times of network requests. In the prior art, the current interaction mode of the developer accessing the Open API of the Open platform is to call one service API each time, and when encountering a complex service scenario, the system implementation is complex by calling one API mode once, so that the consumption of the third party application is increased. Compared with the prior art, the application programming interface calling method provided by the embodiment of the application can reduce the complexity of the system and the consumption of third party application under a complex service scene, and the technical scheme of the embodiment of the application is simple and convenient to realize, convenient to popularize and wider in application range.
Fig. 4 is a schematic structural diagram of an application programming interface calling device according to an embodiment of the present application. As shown in fig. 4, the application programming interface calling device comprises a receiving module 401, an extracting module 402, a disassembling module 403 and a calling module 404, wherein,
The receiving module 401 is configured to receive a request packet sent by a third party application through an open platform, where the request packet at least carries service information of an API of an assembled application programming interface;
The extracting module 402 is configured to extract the assembled API service information from the request packet;
The disassembly module 403 is configured to disassemble the assembled service information into one or more atomic API services;
The calling module 404 is configured to call an atomic interface corresponding to each atomic API service, and return a calling result to the third party application.
The application programming interface calling device can execute the method provided by any embodiment of the application, and has the corresponding functional modules and beneficial effects of executing the method. Technical details not described in detail in this embodiment may refer to the application programming interface calling method provided in any embodiment of the present application.
Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application. Fig. 5 shows a block diagram of an exemplary electronic device suitable for use in implementing embodiments of the application. The electronic device 12 shown in fig. 5 is merely an example and should not be construed as limiting the functionality and scope of use of embodiments of the present application.
As shown in fig. 5, the electronic device 12 is in the form of a general purpose computing device. The components of the electronic device 12 may include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that connects the various system components, including the system memory 28 and the processing units 16.
Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, micro channel architecture (MAC) bus, enhanced ISA bus, video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.
Electronic device 12 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by electronic device 12 and includes both volatile and nonvolatile media, removable and non-removable media.
The system memory 28 may include computer system readable media in the form of volatile memory, such as Random Access Memory (RAM) 30 and/or cache memory 32. The electronic device 12 may further include other removable/non-removable, volatile/nonvolatile computer system storage media. By way of example only, storage system 34 may be used to read from or write to non-removable, nonvolatile magnetic media (not shown in FIG. 5, commonly referred to as a "hard disk drive"). Although not shown in fig. 5, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive for reading from or writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In such cases, each drive may be coupled to bus 18 through one or more data medium interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to carry out the functions of embodiments of the application.
A program/utility 40 having a set (at least one) of program modules 42 may be stored in, for example, memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each or some combination of which may include an implementation of a network environment. Program modules 42 generally perform the functions and/or methods of the embodiments described herein.
The electronic device 12 may also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), one or more devices that enable a user to interact with the electronic device 12, and/or any devices (e.g., network card, modem, etc.) that enable the electronic device 12 to communicate with one or more other computing devices. Such communication may occur through an input/output (I/O) interface 22. Also, the electronic device 12 may communicate with one or more networks such as a Local Area Network (LAN), a Wide Area Network (WAN) and/or a public network, such as the Internet, through a network adapter 20. As shown, the network adapter 20 communicates with other modules of the electronic device 12 over the bus 18. It should be appreciated that although not shown in FIG. 5, other hardware and/or software modules may be used in connection with electronic device 12, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, data backup storage systems, and the like.
The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, for example, implementing an application programming interface calling method provided by an embodiment of the present application.
The embodiment of the application also provides a computer storage medium.
The computer-readable storage media of embodiments of the present application may take the form of any combination of one or more computer-readable media. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
The computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, either in baseband or as part of a carrier wave. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, smalltalk, C ++ and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computer (for example, through the Internet using an Internet service provider).
The embodiment of the application also provides a computer program product.
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include being implemented in one or more computer program products, which may include one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be a special or general purpose programmable processor, operable to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
Note that the above is only a preferred embodiment of the present application and the technical principle applied. It will be understood by those skilled in the art that the present application is not limited to the particular embodiments described herein, but is capable of various obvious changes, rearrangements and substitutions as will now become apparent to those skilled in the art without departing from the scope of the application. Therefore, while the application has been described in connection with the above embodiments, the application is not limited to the embodiments, but may be embodied in many other equivalent forms without departing from the spirit or scope of the application, which is set forth in the following claims.