HTTP (Hyper Text Transport Protocol) multi-interface arrangement, combination and analysis method and device

Abstract

The invention provides an HTTP protocol multi-interface arrangement, combination and analysis method and device, and the method comprises the steps: sorting and calling target interfaces needing to be called based on an execution strategy selected by a user according to a business demand, and the execution strategy comprises a calling strategy and / or a caching strategy; the number of the target interfaces is at least one; the method comprises the following steps: when an execution strategy aiming at a target interface is received, determining a corresponding calling path, a calling parameter and a cache identifier according to the execution strategy and identity information of the target interface; determining a calling sequence of the target interface according to a preset arrangement rule; according to the calling sequence, calling the target interface according to the calling path, the calling parameter and the cache identifier; and after calling is completed, outputting an execution result, analyzing the execution result, and outputting an analysis result. And calling interfaces are dynamically sorted based on a strategy, and the execution efficiency and flexibility are improved in combination with cache optimization.

Description

Technical Field

[0001] This application relates to the field of computer software technology, and in particular to a method and apparatus for parsing and arranging multiple interfaces of the HTTP protocol. Background Technology

[0002] The HTTP protocol is one of the most widely used application layer protocols in the modern Internet, used to transmit data between clients and servers. Existing interface execution systems typically call interfaces and process results through fixed processes, involving the coordinated operation of modules such as strategy execution, parameter injection, sequence control, cache reuse, and result parsing.

[0003] These systems are primarily used in scenarios such as enterprise service integration and automated business process management. For example, they involve calling third-party APIs to complete data synchronization, transaction processing, or user authentication, requiring the integration of multiple interfaces and their orderly execution according to business logic. Their value lies in improving the standardization and efficiency of API calls, reducing manual intervention costs, and supporting the automated implementation of business processes.

[0004] However, existing technologies still have the following problems in terms of flexibility of multiple interface calls, parameter processing, result parsing and cache management: the interface call method is single, the parameter processing is complex, the result parsing method is fixed, and there is a lack of efficient cache management mechanism. Summary of the Invention

[0005] In view of the above problems, this application is made to provide an HTTP protocol multi-interface orchestration and parsing method and apparatus that overcomes or at least partially solves the above problems, comprising:

[0006] A method for orchestrating and parsing multiple interfaces in the HTTP protocol, wherein the method sorts and invokes target interfaces to be called based on an execution strategy selected by the user for business needs, wherein the execution strategy includes an invocation strategy and / or a caching strategy; and the target interface includes at least one.

[0007] The steps include:

[0008] When the execution policy for the target interface is received, the corresponding call path, call parameters, and cache identifier are determined based on the execution policy and the identity information of the target interface;

[0009] The calling order of the target interfaces is determined according to preset orchestration rules;

[0010] Based on the stated invocation order, the target interface is invoked according to the invocation path, the invocation parameters, and the cache identifier;

[0011] After the call is complete, the execution result is output, the execution result is parsed, and the parsing result is output.

[0012] Furthermore, the invocation strategy includes a timed invocation strategy, a platform invocation strategy, and a proactive reporting strategy.

[0013] Furthermore, the step of determining the corresponding call path, call parameters, and cache identifier based on the execution strategy and the identity information of the target interface includes the process of determining the call parameters:

[0014] The calling parameters are determined based on the identity information of the target interface; values ​​are then assigned to the calling parameters.

[0015] Furthermore, the calling parameters include: constants, built-in parameters, and interface signature algorithms; the step of assigning values ​​to the calling parameters includes:

[0016] When the calling parameter is a constant, a predefined constant is selected for injection, and the preset fixed constant value is directly appended to or replaced in the business requirement parameter;

[0017] When the calling parameter is a built-in parameter, a predefined built-in parameter is selected for injection;

[0018] When the calling parameter is an interface signature algorithm, the business requirement parameter is matched according to the regular expression rules pre-configured for the target interface, and the corresponding value that is successfully matched is extracted and injected.

[0019] Furthermore, the built-in parameters include the current time point and a random number; the interface signature algorithm includes a variety of commonly used signature algorithms and a custom signature algorithm.

[0020] Furthermore, the step of invoking the target interface according to the invocation order, the invocation path, the invocation parameters, and the cache identifier includes the process of the target interface determining whether to invoke the cache identifier:

[0021] When a caching policy is received, the cache identifier is valid, and the target interface invokes the cache identifier;

[0022] When no caching policy is received, the cache identifier is invalid, and the target interface will not call the cache identifier.

[0023] Furthermore, the steps of outputting the execution result after the call is completed, parsing the execution result and outputting the parsing result include: outputting the execution result of calling the target interface after the call is completed, parsing the execution result using template configuration and / or script configuration, and outputting the parsing result after the parsing is completed.

[0024] An HTTP protocol multi-interface orchestration and parsing apparatus is used to sort and invoke target interfaces to be called based on an execution strategy selected by the user for business needs, wherein the execution strategy includes an invocation strategy and / or a caching strategy; and the target interface includes at least one.

[0025] The device includes:

[0026] The execution strategy selection module is used to determine the corresponding call path, call parameters, and cache identifier based on the execution strategy and the identity information of the target interface when the execution strategy for the target interface is received.

[0027] An interface orchestration module is used to determine the calling order of the target interface according to a preset orchestration rule; and to call the target interface according to the calling order, the calling path, the calling parameters, and the cache identifier.

[0028] The result parsing module is used to output the execution result after the call is completed, and to parse the execution result and output the parsing result.

[0029] A computer device is characterized by comprising a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method as described in any embodiment of this application.

[0030] A computer-readable storage medium is characterized in that a computer program is stored on the computer-readable storage medium, the computer program being executed by a processor to implement the method as described in any embodiment of this application.

[0031] This application has the following advantages:

[0032] In the embodiments of this application, addressing the issue of the limited interface invocation methods in existing technologies, this application provides a solution for determining the invocation order of target interfaces based on preset orchestration rules. Specifically, the method sorts and invokes target interfaces based on an execution strategy selected by the user for business needs. The execution strategy includes an invocation strategy and / or a caching strategy. The target interfaces include at least one. The steps include: upon receiving the execution strategy for the target interface, determining the corresponding invocation path, invocation parameters, and cache identifier based on the execution strategy and the target interface's identity information; determining the invocation order of the target interfaces according to preset orchestration rules; invoking the target interfaces according to the invocation order, following the invocation path, invocation parameters, and cache identifier; outputting the execution result after invocation, parsing the execution result, and outputting the parsing result. By sorting and invoking target interfaces using the user-selected execution strategy, the problem of limited traditional interface invocation methods and complex parameter processing is solved. Combining the caching strategy with the cache identifier optimizes the cache management mechanism. Determining the invocation order of target interfaces through preset orchestration rules, executing the invocation according to the invocation path, invocation parameters, and cache identifier, and then parsing the result, solves the defect of fixed result parsing methods, improving invocation flexibility and efficiency. Attached Figure Description

[0033] To more clearly illustrate the technical solution of this application, the drawings used in the description of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart illustrating the steps of an HTTP protocol multi-interface orchestration and parsing method according to an embodiment of this application;

[0035] Figure 2 This is a structural block diagram of an HTTP protocol multi-interface orchestration and parsing device provided in one embodiment of this application;

[0036] Figure 3 This is a schematic diagram of the operation interface of a specific example of an HTTP protocol multi-interface orchestration and combination parsing method and apparatus provided in an embodiment of this application;

[0037] Figure 4 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0038] To make the objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0039] Through analysis of existing technologies, the inventors discovered that current HTTP protocols lack flexibility in multi-interface calls and cannot dynamically adapt to complex business scenarios. Specifically, this manifests in the following ways: They typically employ a fixed interface call order and method, unable to dynamically adjust according to business needs, resulting in a single interface call method; parameter processing is fragmented and complex, lacking a unified management and parsing mechanism, leading to complex parameter handling; result parsing is usually fixed to a specific format, unable to flexibly adapt to different business requirements, resulting in a fixed result parsing method; there is a lack of efficient cache management mechanisms, leading to duplicate calls and resource waste, resulting in insufficient cache management; and execution strategies are fixed, failing to meet the needs of various scenarios such as scheduled calls, platform calls, and proactive reporting.

[0040] Based on the above systematic analysis, this invention aims to solve the above problems and provide a flexible, efficient, and scalable method for arranging and parsing multiple interfaces of the HTTP protocol.

[0041] Reference Figure 1 This application illustrates an embodiment of an HTTP protocol multi-interface orchestration and parsing method. The method sorts and invokes target interfaces to be called based on an execution strategy selected by the user for business needs. The execution strategy includes an invocation strategy and / or a caching strategy. The target interface includes at least one.

[0042] The steps include:

[0043] S110. When the execution policy for the target interface is received, the corresponding call path, call parameters, and cache identifier are determined based on the execution policy and the identity information of the target interface.

[0044] S120. Determine the calling order of the target interface according to the preset arrangement rules;

[0045] S130. According to the calling order, the target interface is called according to the calling path, the calling parameters, and the cache identifier;

[0046] S140. After the call is completed, output the execution result, parse the execution result and output the parsing result.

[0047] In the embodiments of this application, addressing the issue of the limited interface invocation methods in existing technologies, this application provides a solution for determining the invocation order of target interfaces based on preset orchestration rules. Specifically, the method sorts and invokes target interfaces based on an execution strategy selected by the user for business needs. The execution strategy includes an invocation strategy and / or a caching strategy. The target interfaces include at least one. The steps include: upon receiving the execution strategy for the target interface, determining the corresponding invocation path, invocation parameters, and cache identifier based on the execution strategy and the target interface's identity information; determining the invocation order of the target interfaces according to preset orchestration rules; invoking the target interfaces according to the invocation order, following the invocation path, invocation parameters, and cache identifier; outputting the execution result after invocation, parsing the execution result, and outputting the parsing result. By sorting and invoking target interfaces using the user-selected execution strategy, the problem of limited traditional interface invocation methods and complex parameter processing is solved. Combining the caching strategy with the cache identifier optimizes the cache management mechanism. Determining the invocation order of target interfaces through preset orchestration rules, executing the invocation according to the invocation path, invocation parameters, and cache identifier, and then parsing the result, solves the defect of fixed result parsing methods, improving invocation flexibility and efficiency.

[0048] The following will further explain an HTTP protocol multi-interface orchestration and parsing method in this exemplary embodiment.

[0049] It's important to note that HTTP, or Hypertext Transfer Protocol, is the fundamental communication rule for data transmission between clients and servers. Building upon this, by configuring multiple execution strategy selectors, such as invocation strategy selectors and caching strategy selectors, the process logic of interface orchestration can be decoupled from specific business requirements. This enables dynamically adjustable business configuration capabilities. Users do not need to modify the code structure of the interface orchestration itself; they can simply switch between different strategies using selectors to adapt to different business scenarios. Specifically, users can define whether to enable caching strategies. For example, for frequently called interfaces such as authorization and login interfaces with low data update frequency, a caching mechanism is typically enabled. By storing verified tokens or session information, repeated calls to the authentication server are avoided, effectively saving system resources and improving overall response efficiency.

[0050] As described in step S110, when the execution policy for the target interface is received, the corresponding call path, call parameters, and cache identifier are determined based on the execution policy and the identity information of the target interface.

[0051] In one embodiment of the present invention, the specific process of step S110, "when the execution policy for the target interface is received, the corresponding call path, call parameters, and cache identifier are determined based on the execution policy and the identity information of the target interface," can be further explained in conjunction with the following description.

[0052] As described in the following steps, the invocation strategy includes a timed invocation strategy, a platform invocation strategy, and a proactive reporting strategy;

[0053] It should be noted that during execution, the invocation status of the scheduled invocation strategy, platform invocation strategy, and proactive reporting strategy can be dynamically switched. The scheduled invocation strategy invokes the connector according to the configured invocation interval and periodicity; the platform invocation strategy adds the connector to the unified routing engine and provides a unified interface for external calls; the proactive reporting strategy provides corresponding request paths based on user-configured request rules. Dynamic switching between multiple strategies adapts to different scenarios, scheduled invocation ensures periodic tasks, platform invocation simplifies operations with a unified interface, and proactive reporting supports customized requests, significantly improving system flexibility and scenario adaptability.

[0054] The following steps include the process of determining the calling parameters: determining the calling parameters based on the identity information of the target interface; and assigning values ​​to the calling parameters.

[0055] It should be noted that by using a hierarchical determination and assignment logic of identity information, parameter items, and parameter values, the blindness of parameter configuration can be avoided. This ensures that parameters are strongly correlated with interface functions, such as authorization interfaces carrying only necessary authentication parameters, and also supports dynamic adjustment of parameter values ​​according to business scenarios, such as real-time interfaces assigning values ​​according to the current timestamp. Ultimately, this improves the adaptability and accuracy of interface calls.

[0056] As described in the following steps, the calling parameters include: constants, built-in parameters, and interface signature algorithms; the step of assigning values ​​to the calling parameters includes: when the calling parameter is a constant, selecting a predefined constant for injection, and directly appending or replacing the preset fixed constant value to the business requirement parameter; when the calling parameter is a built-in parameter, selecting a predefined built-in parameter for injection; when the calling parameter is an interface signature algorithm, performing regular expression matching on the business requirement parameter according to the pre-configured regular expression rules of the target interface, and extracting the corresponding value of the successfully matched value for injection.

[0057] It's important to note that the API signature algorithm is not only a form of parameter injection, but also a core mechanism for ensuring the legitimacy and security of API calls. Specifically, it uses regular expressions to match and extract business requirement parameters, such as timestamps, random numbers, and user IDs. These parameters are then encrypted using a preset signature key to generate a unique signature value, which is injected into the call parameters. Upon receiving the request, the server recalculates the signature using the same algorithm and compares it with the signature in the request: if they match, the parameters have not been tampered with and the request source is legitimate; if they do not match, the call is rejected. This closed-loop mechanism of regular expression extraction, signature generation, and server-side verification effectively prevents security risks such as unauthorized API calls and data tampering, making it a crucial link in API security protection.

[0058] As described in the following steps, the built-in parameters include the current time point and a random number; the interface signature algorithm includes a variety of commonly used signature algorithms and a custom signature algorithm.

[0059] It should be noted that the current time point in the built-in parameters is mainly used to prevent replay attacks. By limiting the effective time window of the request, such as within 5 minutes, it prevents attackers from intercepting and reusing old parameters to launch illegal requests. The random number generates a unique identifier for each request, further reducing the risk of repeated requests being reused. Together, they enhance the timeliness and uniqueness of the interface call.

[0060] As described in step S120, the calling order of the target interface is determined according to the preset orchestration rules.

[0061] It should be noted that the preset orchestration rules are the core logical basis for driving the rationalization of the interface call order. Essentially, they transform discrete target interfaces into an ordered business flow through formal rule definitions, such as dependencies, execution priorities, and conditional branches. Through the explicit definition of these rules, the call order of target interfaces is no longer a hard-coded, fixed process, but rather a configurable logic that can be flexibly adjusted according to business needs. This avoids errors caused by manual orchestration and improves the system's adaptability to complex business scenarios, providing key technical support for achieving dynamic and scalable interface calls.

[0062] In one embodiment of the present invention, the specific process of "determining the calling order of the target interface according to the preset orchestration rules" in step S120 can be further explained in conjunction with the following description.

[0063] As described in the following steps, multiple interfaces are combined according to business logic through connectors to achieve complete business logic functions. The connector is a set of interfaces orchestrated according to business requirements. When calling the target interface within the connector, data interaction is performed through the northbound interface and the southbound interface.

[0064] In one embodiment of the present invention, the specific process of "data interaction through the northbound and southbound interfaces when calling the target interface within the connector" can be further described in conjunction with the following description.

[0065] When calling the target interface, data interaction is handled through northbound and southbound interfaces. The northbound interface reports underlying data or execution results to the upper-level system; for example, after a call, the parsed results are passed to the management platform via the northbound interface. The southbound interface collects data from underlying devices or sends commands; for example, during a call, the real-time device status is obtained via the southbound interface. By clearly defining the direction of data interaction through the northbound / southbound interfaces, bidirectional communication between the lower and middle-to-high-level systems is achieved: the northbound interface facilitates the upward transmission of underlying data / results, such as parsed results directly reaching the management platform, improving the real-time performance of upper-level monitoring; the southbound interface strengthens the connection to underlying devices, such as real-time status collection / command issuance, ensuring the accuracy of device control, and ultimately enhancing the efficiency of cross-level data flow and system collaboration capabilities.

[0066] As described in step S130, the target interface is invoked according to the invocation order, the invocation path, the invocation parameters, and the cache identifier.

[0067] It should be noted that the process of calling the target interface according to the calling parameters is essentially a parameter configuration process. This decouples the parameters required for the interface call from the code logic and centrally manages them through independent configuration files or standardized templates. This model supports dynamic parameter adjustment: when business requirements change, there is no need to modify the interface call code; only the configuration file or template needs to be updated to iterate the parameter rules. Simultaneously, configuration files can be stored separately according to environment or business scenario, and the corresponding configuration is dynamically loaded based on the context during the call, ensuring accurate parameter adaptation.

[0068] In one embodiment of the present invention, the specific process of "calling the target interface according to the call path, the call parameters and the cache identifier according to the call order" in step S130 can be further described in conjunction with the following description.

[0069] The following steps include the process by which the target interface determines whether to invoke the cache identifier: when a cache policy is received, the cache identifier is valid, and the target interface invokes the cache identifier; when no cache policy is received, the cache identifier is invalid, and the target interface does not invoke the cache identifier.

[0070] It should be noted that the logic for invoking the cache identifier is essentially a policy-driven dynamic caching decision-making mechanism. It explicitly controls whether the target interface enables caching functionality based on the condition of "whether a caching policy has been received." Specifically:

[0071] When the system receives a clear caching policy, the cache identifier is marked as valid. When the target interface is called, it will first check whether there is historical data in the cache pool that meets the conditions: if it exists, it will directly read the cache and return it, avoiding repeated calls to the underlying interface or repeated calculations, and significantly reducing response latency; if it does not exist, it will execute the original call logic and write the result to the cache pool for subsequent use.

[0072] Conversely, if no caching policy is received, the cache is marked as invalid, and the target interface will skip the cache verification process and directly call the underlying interface to obtain the latest data, ensuring the real-time performance and accuracy of the results.

[0073] This design achieves flexible and controllable caching mechanisms through a closed-loop logic of strategies, identifiers, and behaviors: it can reduce system load and improve user experience through caching in scenarios requiring performance optimization; and it can prevent dirty data by disabling caching in scenarios requiring real-time data, balancing the needs of performance and data accuracy. It is the core strategy execution link of cache management.

[0074] As described in step S140, after the call is completed, the execution result is output, the execution result is parsed, and the parsing result is output.

[0075] It should be noted that result parsing involves processing and transforming the results of API calls.

[0076] In one embodiment of the present invention, the specific process of "outputting the execution result after the call is completed, parsing the execution result and outputting the parsing result" in step S140 can be further explained in conjunction with the following description.

[0077] As described in the following steps, after the call is completed, the execution result of the call to the target interface is output, the execution result is parsed using template configuration and / or script configuration, and the parsing result is output after the parsing is completed;

[0078] It should be noted that template configuration parsing is used for parsing response results with relatively clear and simple structures, suitable for delivery personnel; script configuration parsing is used for complex business parsing, suitable for developers or delivery personnel with some development capabilities. Together, they form a parsing system where standardized templates cover routine requirements and flexible scripts handle complex scenarios. This lowers the barrier to entry for delivery personnel while ensuring developers' ability to handle special needs, ultimately achieving a dual improvement in result parsing efficiency and adaptability.

[0079] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0080] Reference Figure 2This illustration shows an HTTP protocol multi-interface orchestration and parsing apparatus according to an embodiment of this application; used to sort and invoke target interfaces to be invoked based on an execution strategy selected by the user for business needs, wherein the execution strategy includes an invocation strategy and / or a caching strategy; the target interface includes at least one;

[0081] The device includes:

[0082] The execution strategy selection module 310 is used to determine the corresponding call path, call parameters, and cache identifier based on the execution strategy and the identity information of the target interface when the execution strategy for the target interface is received.

[0083] The interface orchestration module 320 is used to determine the calling order of the target interface according to a preset orchestration rule; and to call the target interface according to the calling order, the calling path, the calling parameters, and the cache identifier.

[0084] The result parsing module 330 is used to output the execution result after the call is completed, parse the execution result and output the parsing result.

[0085] In one embodiment of the present invention, the strategy selection module 310 includes:

[0086] The unified routing engine submodule is used to map external requests to the corresponding interface groups;

[0087] In one embodiment of the present invention, the interface orchestration module 320 includes:

[0088] The parameter parsing submodule is used to define a unified parameter processing pipeline, which manages the parameters of the interface call through configuration files or templates, making it easy to adjust dynamically.

[0089] The cache decision-maker submodule is used to manage the cache storage and retrieval strategies.

[0090] Reference Figure 3 The diagram illustrates a specific example of an operation interface for a multi-interface orchestration and parsing method for the HTTP protocol provided in an embodiment of this application; the following is in conjunction with... Figure 3 The specific implementation method is described according to the direction of data flow.

[0091] Taking access control system integration as an example, the system needs to meet the following requirements:

[0092] Get real-time access control status, such as door opening / closing and alarm events; get access control records; synchronize personnel and permissions through the application layer and perception layer; implement visitor appointment check-in function and visitor access QR code query.

[0093] The edge layer is configured with an active reporting strategy to receive real-time access control status and alarm events actively reported by access control devices in the perception layer. The parsed data is then pushed to the capability layer via a result parser, and finally reaches the upper-layer application. The active reporting strategy and reporting route are configured and provided to the access control device manufacturer; since the parameters are reported through a third party, no parameter configuration is required; a script is configured to parse the reported data.

[0094] The edge layer is configured with a timed data collection strategy to periodically retrieve personnel access records from access control devices. The parsed data is then pushed to the capability layer via a result parser, ultimately reaching the upper-layer application. The timed collection strategy is configured with a collection interval of 60 seconds. For the interface orchestration, the access control login interface is configured first, including the request path, login username and password, and the interface identifier is defined as "login". Result caching is enabled, and the cache time is set to 7200 seconds. Configure the access control record interface, including the request path and request parameters. This includes the authorization token in the request header, named `Authorization` with a value of `{{login.result.token}}`. The token returned by the login interface serves as the authorization information for the access control record interface. Configure the request body parameters, including the start time (`startTime`) and end time (`endTime`), and the pagination parameters `pageIndex` and `maxResultCount`. The pagination parameters are constants, configured as 1 and 1000 respectively. `startTime` is set to `{{$dateTime}}-60`, and `endTime` is set to `{{$dateTime}}`. `{{$dateTime}}` represents the current time, while `{{$dateTime}}-60` represents the time 60 seconds prior to the current time. This means the access control record is queried every 60 seconds, with the query range being records older than 60 seconds. Configure the interface signature. The interface signature algorithm is to sort all parameters alphabetically, combine them in key:value format, and calculate their MD5 value. This is quite common, so the built-in signature algorithm can be used. Configure the signature parameter sign with the value {{$md5Sign}}.

[0095] This service is relatively simple, so there is no need to configure the order. By default, it proceeds from top to bottom, first logging in to obtain a token, and then obtaining the access record based on the token.

[0096] After the interface orchestration is complete, configure the parsing script to convert the output into the data format required by the business logic. The JavaScript code is as follows:

[0097]

[0098]

[0099]

[0100] The edge layer configures the platform invocation strategy. The application layer sends the parameters for adding, deleting, and modifying personnel and permissions to the edge layer. The edge layer uses a unified routing engine to map these parameters to the corresponding connectors and then forwards the requests to the access control devices in the perception layer. The platform invocation strategy is configured; interfaces are orchestrated, with the login interface configured identically, and interfaces for adding and modifying personnel configured. The invocation logic needs to be orchestrated: if the platform invocation parameters include a personnel ID, then modification is performed; otherwise, addition is performed. This rule controls the interface flow. The returned configuration results are similar.

[0101] The edge layer configures the platform's invocation strategy. The application layer sends visitor appointment parameters to the edge layer. The edge layer maps these parameters to the visitor appointment connector via a unified routing engine and then sends the request to the access control device in the perception layer. When a visitor arrives, the application layer sends the visitor ID to the edge layer, and the edge layer requests the access control device to return the QR code data.

[0102] Reference Figure 4 The computer device illustrating the HTTP protocol multi-interface orchestration and parsing method of the present invention may specifically include the following:

[0103] The computer device 12 described above is in the form of a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0104] Bus 18 refers to one or more of several types of bus 18 architectures, including memory bus 18 or memory controller, peripheral bus 18, graphics acceleration port, processor, or local bus 18 using any of the various bus 18 architectures. For example, these architectures include, but are not limited to, Industry Standard Architecture (ISA) bus 18, Micro Channel Architecture (MAC) bus 18, Enhanced ISA bus 18, Audio / Video Electronics Standards Association (VESA) local bus 18, and Peripheral Component Interconnect (PCI) bus 18.

[0105] Computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer device 12, including volatile and non-volatile media, removable and non-removable media.

[0106] 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. Computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (commonly referred to as a "hard disk drive"). Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (such as a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. The memory may include at least one program product having a set (e.g., at least one) of program modules 42 configured to perform the functions of the embodiments of the present invention.

[0107] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in memory. Such program modules 42 include—but are not limited to—an operating system, one or more application programs, other program modules 42, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0108] Computer device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, camera, etc.), and with one or more devices that enable a user to interact with the computer device 12, and / or with any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, computer device 12 can also communicate with one or more networks (e.g., local area network (LAN)), wide area network (WAN), and / or public networks (e.g., the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of computer device 12 via bus 18. It should be understood that, although... Figure 4 Not shown, it can be combined with computer device 12 to use other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing unit 16, external disk drive array, RAID system, tape drive and data backup storage system 34, etc.

[0109] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing an HTTP protocol multi-interface orchestration and parsing method provided in this embodiment of the invention.

[0110] That is, when the processing unit 16 executes the above program, it performs the following: when the execution strategy for the target interface is received, it determines the corresponding call path, call parameters, and cache identifier based on the execution strategy and the identity information of the target interface; it determines the call order of the target interface based on the preset orchestration rules; it calls the target interface according to the call order, the call path, the call parameters, and the cache identifier; after the call is completed, it outputs the execution result, parses the execution result, and outputs the parsing result.

[0111] In this embodiment of the invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements an HTTP protocol multi-interface orchestration and parsing method as provided in all embodiments of this application:

[0112] That is, when the program is executed by the processor, it implements the following: when the execution strategy for the target interface is received, the corresponding call path, call parameters, and cache identifier are determined according to the execution strategy and the identity information of the target interface; the call order of the target interface is determined according to the preset orchestration rules.

[0113] According to the calling order, the target interface is called according to the calling path, the calling parameters, and the cache identifier; after the call is completed, the execution result is output, the execution result is parsed, and the parsing result is output.

[0114] Any combination of one or more computer-readable media may be used. A computer-readable medium may be a computer-to-signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium that contains or stores a program that may be used by or in connection with an instruction execution system, apparatus, or device.

[0115] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0116] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—and conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider). The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments; similar or identical parts between embodiments can be referred to interchangeably.

[0117] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0118] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0119] The above provides a detailed description of the HTTP protocol multi-interface orchestration and combination parsing method and apparatus provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for parseting and combining multiple interfaces of the HTTP protocol, characterized in that, The method sorts and invokes the target interfaces to be called based on the execution strategy selected by the user according to business needs, wherein the execution strategy includes a calling strategy and / or a caching strategy; the target interface includes at least one. The steps include: When the execution policy for the target interface is received, the corresponding call path, call parameters, and cache identifier are determined based on the execution policy and the identity information of the target interface; The calling order of the target interfaces is determined according to preset orchestration rules; Based on the stated invocation order, the target interface is invoked according to the invocation path, the invocation parameters, and the cache identifier; After the call is complete, the execution result is output, the execution result is parsed, and the parsing result is output.

2. The method according to claim 1, characterized in that, The invocation strategies include timed invocation strategies, platform invocation strategies, and proactive reporting strategies.

3. The method according to claim 1, characterized in that, The step of determining the corresponding call path, call parameters, and cache identifier based on the execution strategy and the identity information of the target interface includes the process of determining the call parameters: The calling parameters are determined based on the identity information of the target interface; The calling parameters are assigned values.

4. The method according to claim 3, characterized in that, The calling parameters include: constants, built-in parameters, and interface signature algorithms; the step of assigning values ​​to the calling parameters includes: When the calling parameter is a constant, a predefined constant is selected for injection, and the preset fixed constant value is directly appended to or replaced in the business requirement parameter; When the calling parameter is a built-in parameter, a predefined built-in parameter is selected for injection; When the calling parameter is an interface signature algorithm, the business requirement parameter is matched according to the regular expression rules pre-configured for the target interface, and the corresponding value that is successfully matched is extracted and injected.

5. The method according to claim 4, characterized in that, The built-in parameters include the current time point and a random number; the interface signature algorithm includes a variety of commonly used signature algorithms and a custom signature algorithm.

6. The method according to claim 1, characterized in that, The step of invoking the target interface according to the invocation order, the invocation path, the invocation parameters, and the cache identifier includes the process of the target interface determining whether to invoke the cache identifier: When a caching policy is received, the cache identifier is valid, and the target interface invokes the cache identifier; When no caching policy is received, the cache identifier is invalid, and the target interface will not call the cache identifier.

7. The method according to claim 1, characterized in that, The steps of outputting the execution result after the call is completed, parsing the execution result and outputting the parsing result include: outputting the execution result of calling the target interface after the call is completed, parsing the execution result using template configuration and / or script configuration, and outputting the parsing result after the parsing is completed.

8. An HTTP protocol multi-interface orchestration and parsing device, characterized in that, The apparatus is applied to the method described in claims 1-7, and is used to sort and invoke target interfaces to be invoked based on the execution strategy selected by the user for business needs, wherein the execution strategy includes an invocation strategy and / or a caching strategy; the target interface includes at least one; The device includes: The execution strategy selection module is used to determine the corresponding call path, call parameters, and cache identifier based on the execution strategy and the identity information of the target interface when the execution strategy for the target interface is received. An interface orchestration module is used to determine the calling order of the target interface according to a preset orchestration rule; and to call the target interface according to the calling order, the calling path, the calling parameters, and the cache identifier. The result parsing module is used to output the execution result after the call is completed, and to parse the execution result and output the parsing result.

9. A computer device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images