HTTP message dynamic orchestration apparatus and method

Abstract

The application relates to an HTTP message dynamic arrangement device and method. The device comprises a configuration module, which processes and stores data; a strategy module, which receives an HTTP request message sent by an HTTP request client, and performs access authentication, IP black and white list checking, access resource permission checking, access resource state checking and flow control according to a strategy; and a scheduling module, which arranges according to an arrangement script and generates an HTTP response message, and sends the HTTP response message to the HTTP request client. In the above manner, the user's access process of the HTTP message can be effectively simplified, the service access efficiency is greatly improved, and the quality of the network service and the user experience are remarkably improved.

Description

Technical Field

[0001] This invention relates to an HTTP message dynamic orchestration apparatus and method. Background Technology

[0002] The core of the next stage of telecommunications network transformation is IT integration, building a new generation network with globally scalable resources, fully open capabilities, elastically scalable capacity, and flexibly adjustable architecture. Essentially, this means hosting the network on a large cloud platform. With the emergence of new network architectures such as NFV / SDN, operators are beginning to simplify their service networks and change their existing siloed communication service delivery systems.

[0003] To meet the network architecture requirements of new business development models, operators' various value-added service plans have evolved into a standardized voice / media / signaling capability platform (providing capability call interfaces) and an intelligent service server (providing existing standardized and personalized services). Among these, the cloud media encapsulation open platform can be built on an NFV architecture, encapsulating IMS media functions and possessing business development capabilities, providing playback, digit collection, recording, and IVR as application programming interfaces. However, the current capability encapsulation side lacks security control support, making it impossible to monitor system QoS in terms of interoperability, availability, performance, and security, and unable to manage interface, media, signaling, and system security. Summary of the Invention

[0004] To address the problems existing in the prior art, the present invention aims to provide a technical solution for a dynamic HTTP message orchestration device and method, with the goal of providing authentication and orchestration (field permissions) capabilities to external parties without any modifications during the HTTP interface service provision process.

[0005] The HTTP message dynamic orchestration device is characterized by comprising:

[0006] Configuration module: processes and stores data;

[0007] Policy module: Receives HTTP request messages sent by HTTP request clients and performs access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and flow control according to the policy.

[0008] Scheduling module: It performs scheduling according to the scheduling script and generates HTTP response messages, and sends the HTTP response messages to the HTTP request client.

[0009] The HTTP message dynamic orchestration method is characterized by the following steps:

[0010] Step S101: The configuration module processes and stores the data;

[0011] Step S102: The strategy module receives the HTTP request message sent by the HTTP request client;

[0012] In step S103, the policy module performs access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and traffic control according to the policy.

[0013] Step S104: The scheduling module performs orchestration according to the orchestration script and generates an HTTP response message;

[0014] In step S105, the scheduling module sends the HTTP response message to the HTTP request client.

[0015] The HTTP message dynamic orchestration method is characterized in that step S101 is independent of the application interface orchestration and scheduling process. It mainly processes and stores the data required for the execution of steps S102, S103, S104, and S105 according to the business model.

[0016] The application interface orchestration, or orchestration for short, refers to the process of combining and executing multiple application interface requests in a specific order using an application interface model and an orchestration script to achieve more complex business logic or functions.

[0017] The application interface model includes an application interface pattern and an application interface context. The application interface pattern expresses the constraints of the application interface, while the application interface context expresses the specific information of a particular access to the application interface. The application interface pattern is a description of the application interface, and the application interface context is the specific carrier of the application interface.

[0018] The HTTP message dynamic orchestration method is characterized in that the orchestration script is a scripting language, which, in addition to supporting the basic features of a scripting language, also supports calling methods of a pre-defined object, supports dynamic updates, and supports adding, deleting, and modifying the application interface context according to the application interface pattern.

[0019] The preset object is a set of predefined operations in the main language that calls the orchestration script, wherein the operations of the preset object can be extended and supported;

[0020] The dynamic update refers to the ability to update the orchestration script without restarting the device when the script changes.

[0021] The aforementioned HTTP message dynamic orchestration method is characterized by a business model as its foundation, used to constrain and abstract the business aspects of HTTP access clients, HTTP response clients, and HTTP application programming interfaces (APIs), and to provide business information support for strategies and orchestration engines. The HTTP access clients and HTTP response clients are abstracted into business functions, with the HTTP access client abstracted as a consumer and the HTTP response client abstracted as a provider. The HTTP APIs are divided into northbound APIs and southbound APIs according to different levels; the northbound APIs are APIs called by consumers, and the southbound APIs are APIs provided by providers.

[0022] The HTTP message dynamic orchestration method described above is characterized by the following implementation process of step S101:

[0023] Step S1011: Process and store the provider data, and store the structured data processed by the provider into the database;

[0024] Step S1012: Process and store the southbound application interface data, and store the structured data processed by the southbound application interface into the database;

[0025] Step S1013: Process and store the northbound application interface data, and store the structured data processed by the northbound application interface into the database;

[0026] Step S1014: Process and store consumer data, storing the structured data processed by consumers into the database;

[0027] Step S1015: Process and store the application data, and store the structured data processed by the application into the database;

[0028] Step S1016: Process and store the application IP blacklist and whitelist data, and store the structured data of the application IP blacklist and whitelist processing into the database;

[0029] Step S1017: Process and store the application authorization data, and store the structured data of the application authorization processing into the database;

[0030] Step S1018: Process and store the application subscription data, and store the structured data of the application subscription processing into the database.

[0031] The HTTP message dynamic orchestration method is characterized in that step S1014 depends on step S1011, and step S1013 depends on step S1012 in some cases; after step S1015, steps S1016, S1017, and S1018 are three processes that can be performed simultaneously, and there is no order among them.

[0032] Step S1013 depends on step S1012 in some cases. This means that the northbound application interface can be associated with zero or more southbound application interfaces, and simple or complex calling logic can be implemented according to the actual orchestration logic. When zero southbound application interfaces are associated, step S1013 does not depend on step S1012. When multiple southbound application interfaces are associated, step S1013 depends on step S1012.

[0033] The HTTP message dynamic orchestration method described above is characterized by the following implementation process for step S103:

[0034] Step S1031: Parse the HTTP request message;

[0035] Step S1032: Perform access authentication. Access authentication supports HTTP Basic authentication and signature authentication.

[0036] Step S1033: Determine whether the authentication is successful. If not, proceed to step S10313; if yes, proceed to step S1034.

[0037] Step S1034: Perform IP blacklist / whitelist verification.

[0038] The IP blacklist / whitelist verification first obtains the hostname or domain name to be accessed from the Host header field in the HTTP request message. Then, based on the application obtained in step S1032, it searches the application IP blacklist / whitelist table for all IP blacklists / whitelists whose application ID is equal to the application ID in the IP blacklist / whitelist table, and iterates through them. If the type of IP blacklist / whitelist in all IP blacklists / whitelists is a whitelist, it then checks whether the hostname or domain name obtained from the header field is the same as the host in the IP blacklist / whitelist in all IP blacklists / whitelists. If they are the same, the request is allowed; otherwise, it is blocked. If the type of IP blacklist / whitelist in all IP blacklists / whitelists is not a whitelist, it then checks whether the hostname or domain name obtained from the header field is the same as the host in the IP blacklist / whitelist in all IP blacklists / whitelists. If they are the same, the request is blocked; otherwise, the request is allowed.

[0039] Step S1035: Determine whether the blacklist / whitelist verification passes. If not, proceed to step S10313; otherwise, proceed to step S1036.

[0040] Step S1036: Perform resource access permission verification.

[0041] The access resource permission verification first obtains the northbound application interface in the current application interface orchestration and scheduling process, and then obtains the application authorization from the application authorization table that is equal to the northbound application interface ID and the application ID is equal to the application ID obtained according to step S1032. If they exist, the access is allowed; otherwise, it is blocked.

[0042] The process of obtaining the northbound application interfaces in the current application interface orchestration and scheduling process involves retrieving all northbound application interfaces from the northbound application interface table and traversing it when starting the HTTP service. The request URI expression of the application interface pattern of the northbound application interface is then listened for. When an HTTP request client accesses the HTTP service, only requests that match the request URI expression of the application interface pattern of the northbound application interface will undergo the application interface orchestration and scheduling process. Therefore, the northbound application interfaces accessed by the current HTTP request client can be obtained throughout the entire application interface orchestration and scheduling process.

[0043] Step S1037: Determine whether the access permission verification passes. If not, proceed to step S10313; otherwise, proceed to step S1038.

[0044] Step S1038: Perform resource access status verification.

[0045] The access resource status verification first obtains the northbound application interface in the current application interface orchestration and scheduling process, and determines whether the status of the northbound application interface is enabled. If not, it is blocked. If it is, it determines whether the status of the application obtained according to step S1032 is enabled. If it is, it is allowed; otherwise, it is blocked.

[0046] Step S1039: Determine whether the access resource status verification passes. If not, proceed to step S10313; otherwise, proceed to step S10310.

[0047] Step S10310: Perform flow control.

[0048] The flow control process involves obtaining the application authorization TPS threshold from step S1036, using the token bucket algorithm for flow control, and setting the number of tokens generated per second as the application authorization TPS threshold. When a token can be obtained, the flow is allowed; otherwise, it is blocked.

[0049] Step S10311: Determine whether the flow control exceeds the threshold. If not, proceed to step S10313; otherwise, proceed to step S10312.

[0050] Step S10312: Forward the HTTP request message to the scheduling module;

[0051] Step S10313: Forward the constructed HTTP response message to the HTTP request client. In the case of non-allowed access, construct an HTTP response message, fill in the HTTP response status code, and forward it to the HTTP request client. Specifically, if access authentication fails, the HTTP response status code is filled in as 401; if IP blacklist / whitelist verification fails, the HTTP response status code is filled in as 403; if access resource permission verification fails, the HTTP response status code is filled in as 403; if access resource status verification fails, the HTTP response status code is filled in as 403; and if flow control fails, the HTTP response status code is filled in as 503.

[0052] The HTTP message dynamic orchestration method is characterized in that the HTTP Basic authentication first decrypts the value of the Authorization field in the HTTP request message header using the HTTP Basic authentication decryption method to obtain the username and password, where the username is the code of the application under the consumer and the password is the password of the application under the consumer. Then, the application table is searched for an application whose code is equal to the username obtained by decryption using the HTTP Basic authentication decryption method. If the application is found and the password of the application is consistent with the password obtained by decryption using the HTTP Basic authentication decryption method, the authentication is considered successful.

[0053] The signature authentication process decrypts the value of the Authorization field in the HTTP request header using a signature authentication decryption method to obtain the username, timestamp, and signature string. The username is the code of the application under the consumer, the timestamp is the timestamp of the HTTP request, and the signature string is the signed string. Then, the difference between the timestamp and the timestamp of the time the device received the request is compared to see if it is within a specified error range. If not, authentication fails. If it is, the application table is searched for an application whose code equals the username obtained through signature authentication decryption. If found, the username, timestamp, and application password obtained through signature authentication decryption are used to create a signature. The resulting string is then compared with the signature obtained through signature authentication decryption; if they match, authentication is considered successful.

[0054] The HTTP message dynamic orchestration method described above is characterized by the following implementation process for step S104:

[0055] Step S1041: Obtain the type of the northbound application interface in the current application interface orchestration and scheduling process;

[0056] Step S1042: Determine the type of the northbound application interface. If it is a request, proceed to step S1043; if it is a push, proceed to step S1044.

[0057] Step S1043: Execute the orchestration script in the northbound application programming interface to process the request logic.

[0058] The request logic processing, orchestration scripts, and general features of orchestration scripts are supported for request flow processing. However, the pre-defined object does not support forwarding the application interface context to the application interface received by the consumer's application at the time of subscription. The pre-defined object forwarding the application interface context to the southbound application interface provided by the provider can convert the application interface context into an HTTP request message, and then forward it to the HTTP response client of the southbound application interface. The HTTP response client returns an HTTP response message, and then generates the application interface context according to the southbound application interface mode and the HTTP response message. Finally, the application interface context is returned. This pre-defined object does not limit the number of times it can be called.

[0059] Step S1044: Execute the application coding script in the northbound application programming interface to obtain the push application.

[0060] The application encoding script obtains the push application by first generating an application interface context based on the application interface mode and HTTP request message of the northbound application interface in the current application interface orchestration and scheduling process, then processing it according to the general characteristics of the application encoding script, returning the push application code, and finally searching for the application whose code is equal to the push application code from the application table.

[0061] Step S1045: Determine whether the push application can be obtained. If not, proceed to step S1049; if yes, proceed to step S1046.

[0062] Step S1046: Obtain application subscriptions based on push applications and northbound application interfaces;

[0063] Step S1047: Determine whether an application subscription can be obtained. If not, proceed to step S1049; if yes, proceed to step S1048.

[0064] Step S1048: Execute the orchestration script in the application subscription to perform push logic processing and obtain the HTTP response message.

[0065] The push logic processing first generates an application interface context based on the application interface mode and HTTP request message of the northbound application interface in the current application interface orchestration and scheduling process. Then, it processes the application interface context according to the general characteristics of the orchestration script and returns the application interface context. Finally, it generates an HTTP response message based on the application interface mode in the application subscription and the returned application interface context.

[0066] Step S1049: Forward the constructed HTTP response message to the HTTP request client. If the push application is not obtained or the application subscription is not obtained, construct an HTTP response message, fill in the HTTP response status code, and forward it to the HTTP request client. When the push application is not obtained, the HTTP response status code is filled in as 404. When the application subscription is not obtained, the HTTP response status code is filled in as 403.

[0067] The advantages of this invention are as follows:

[0068] 1. Without modifying the existing platform, the integration and management of various application programming interfaces (APIs) for northbound requests to southbound and southbound requests to northbound can be achieved, and the business process can be clearly reflected in this invention.

[0069] 2. By abstracting the application programming interface (API), it can be used to pass API-related information in different code frameworks, greatly simplifying the cost of cross-language and cross-framework API integration;

[0070] 3. Using application programming interfaces (APIs) to orchestrate scheduling processes allows APIs to implement more control logic without requiring code modifications;

[0071] 4. After integrating this invention into the platform, it can provide access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and traffic control. No code development is required, significantly improving integration efficiency. Attached Figure Description

[0072] Figure 1 Business model diagram;

[0073] Figure 2 Flowchart of HTTP message dynamic orchestration method;

[0074] Figure 3 A flowchart for data processing and storage;

[0075] Figure 4 This is a flowchart of the strategy execution process;

[0076] Figure 5 To create flowcharts;

[0077] Figure 6 This is a diagram of the direct callback mode;

[0078] Figure 7 This is a diagram of the proxy pattern;

[0079] Figure 8 This is a diagram of a mixed-mode programming model. Detailed Implementation

[0080] The present invention will be further described below with reference to the accompanying drawings:

[0081] This invention relates to a dynamic orchestration device and method based on HTTP messages. It mainly receives HTTP request messages, executes policies, orchestrates the messages, and finally forwards HTTP response messages. This approach can effectively simplify the user's access process to HTTP messages, significantly improve service access efficiency, and substantially enhance the quality of network services and user experience. Example

[0082] This paper provides a method for dynamic orchestration of HTTP messages.

[0083] Step S101, independent of the application programming interface orchestration and scheduling process, mainly functions to process and store the data required for the execution of steps S102, S103, S104, and S105 according to the business model.

[0084] Application Programming Interface (API) orchestration, or simply orchestration, refers to the process of combining and executing multiple API requests in a specific order using an API model and orchestration scripts to achieve more complex business logic or functions.

[0085] An Application Programming Interface (API) model consists of API patterns and API contexts. API patterns express the constraints of an API, while API contexts convey specific information about a particular API access. The API pattern describes the API, and the API context is the concrete implementation of the API.

[0086] The structure of the application programming interface (API) pattern is referenced in Table 1, and the interface of the API context is referenced in Table 2.

[0087] Fields type meaning Example protocal JsonObject Supported protocols protocal.{key} String Where key is the protocol name protocol.{key}.host String Current protocol hostname protocal.{key}.port Int Current protocol port uri String Request URI Expression / api / {apiId} / name method String Request method POST requestHeaders Array Request header requestHeaders[i].name String Request header name Accept requestHeaders[i].value String Request header value application / vnd.eastcom[.version][.param]+json requestHeaders[i].example String Request header examples application / vnd.eastcom.V1+json requestHeaders[i].desc String Request header description version: Version number, param: Operation (undefined). requestQueryParams Array Request Query Parameters requestQueryParams[i].name String query parameter name name requestQueryParams[i].required Boolean Is the query parameter required? true requestQueryParams[i].example String Example of query parameters Xiao Wang requestQueryParams[i].desc String Query parameter description User Name (Left Match Fuzzy Query) responseStatusCode JsonObject Response encoding corresponds to the response map responseStatusCode.{key} String The key is the response code. responseStatusCode.{key}.{value} String value corresponds to the key in the response. response JsonObject response response.{key} String The key is the identifier of the response object. response.{key}.requestBody JsonNode JSON Schema response.{key}.responseHeaders Array Response header response.{key}.responseHeaders[i].name String Response header name Accept response.{key}.responseHeaders[i].value String Response header value application / vnd.eastcom[.version][.param]+json response.{key}.responseHeaders[i].example String Response header examples application / vnd.eastcom.V1+json response.{key}.responseHeaders[i].desc String Response header description version: Version number, param: Operation (undefined). response.{key}.responseBody JsonNode JSON Schema

[0088] Table 1 Application Programming Interface Pattern Structure

[0089] Fields type meaning Example host String Request hostname 10.8.22.31 port Int Request port 6350 protocal String Request Protocol http uri String Request URI / api / c0dc744d3aee11e892cb0025901bf22a / name uriParams JsonObject Uri parameters uriParams.{key} String key is the name of the Uri parameter. apiId uriParams.{key}.{value} JsonNode value is the Uri parameter value. c0dc744d3aee11e892cb0025901bf22a method String Request method POST requestHeaders JsonObject Request header parameters requestHeaders.{key} String The key is the request header name. Accept requestHeaders.{key}.{value} String value is the request header value. application / vnd.eastcom.V1+json requestQueryParams JsonObject query parameters requestQueryParams.{key} String query parameter name name requestQueryParams.{key}.{value} JsonNode query parameter value Xiao Wang requestBody JsonNode Request parameters responseStatusCode Int Response Encoding responseHeaders JsonObject Response header parameters responseHeaders.{key} String The key is the name of the response header. Accept responseHeaders.{key}.{value} String value is the response header value. application / vnd.eastcom.V1+json responseBody JsonNode Response parameters

[0090] Table 2 Application Interface Context Structure

[0091] The scripting language supports basic scripting language features, as well as calling methods of predefined objects, dynamic updates, and adding, deleting, and modifying application interface contexts based on application interface patterns.

[0092] A scripting language is a programming language typically used to write scripted programs. Unlike compiled languages, scripting languages ​​usually do not need to be compiled beforehand; instead, they are interpreted and executed line by line at runtime.

[0093] A preset object is a set of predefined operations in the main language that calls the orchestration script. The operations of the preset object can be extended and supported.

[0094] Forward the application interface context to the southbound application interface provided by the provider;

[0095] Forward the API context to the API that the consumer's application receives when it subscribes;

[0096] Obtain an empty application interface context;

[0097] Return the Basic authentication calculation result based on the username and password;

[0098] Clear the current initial application interface context authentication information;

[0099] Get information about the currently accessed application;

[0100] AES encryption returns a byte array;

[0101] AES decryption returns a string;

[0102] BASE64 encoding returns a string;

[0103] BASE64 decoding returns a string;

[0104] DES encoding returns a byte array;

[0105] DES decoding returns a string;

[0106] MD5 encryption returns a string;

[0107] Returns a UUID;

[0108] Get the current log record object.

[0109] Dynamic updates refer to the ability to update the orchestration script without restarting the device when the script changes.

[0110] The application programming interface orchestration and scheduling process refers to the following steps: S102 The policy module receives the HTTP request message sent by the HTTP request client; S103 The policy module performs IP blacklist / whitelist verification, HTTP access authentication, HTTP access resource permission verification, HTTP access resource status verification, and flow control according to the policy; S104 The scheduling module performs orchestration according to the orchestration script and generates an HTTP response message; S105 The scheduling module sends the HTTP response message to the HTTP request client.

[0111] The business model forms the business foundation for implementing this invention and permeates all devices. It is used to define constraints and business abstractions for HTTP access clients, HTTP response clients, and HTTP application programming interfaces (APIs), and to provide business information support for strategies and orchestration engines. HTTP access clients and HTTP response clients are abstracted into business functions; the HTTP access client is abstracted as a consumer, and the HTTP response client as a provider. HTTP APIs are divided into northbound APIs and southbound APIs according to different levels. Northbound APIs are APIs called by consumers, and southbound APIs are APIs provided by providers, such as... Figure 1 As shown.

[0112] Consumers can be businesses or individuals. Under each consumer are various applications that belong to that consumer. This is a further segmentation of the business based on the consumer. In the actual access process, both consumers and applications are general terms for the business of HTTP request clients.

[0113] Providers offer southbound application programming interfaces (APIs), which can be provided by businesses or individuals. However, unlike consumers, providers directly provide services and do not have subordinate applications like consumers do.

[0114] The southbound application programming interface (API) is the original API provided by the provider; that is, whatever API the southbound provider provides, that is, the southbound API of this invention is the same.

[0115] A northbound application interface is a new application interface generated by orchestrating a southbound application interface. This application interface can be associated with zero or more southbound application interfaces and implement simple or complex calling logic according to the actual orchestration logic.

[0116] There are three processes between applications, northbound application programming interfaces (APIs), and southbound APIs: authorization, subscription, and orchestration. Both authorization and subscription refer to applications wanting to use northbound APIs, but the two processes are slightly different. Authorization refers to northbound access to southbound APIs, where the consumer needs to associate the required northbound API and fill in the concurrency threshold for authorizing access to this API. Subscription refers to southbound requests to northbound APIs, where the consumer needs to associate the required API, the API pattern the consumer receives, and the orchestration script.

[0117] Step S101: The configuration module processes and stores the data.

[0118] The specific implementation process of step S101 is as follows: Figure 3In this process, step S1014 depends on step S1011, and step S1013 depends on step S1012 in some cases. After step S1015, steps S1016, S1017, and S1018 are three processes that can be performed simultaneously, without any order between them.

[0119] Step S1013 depends on step S1012 in some cases. This means that the northbound application interface can be associated with zero or more southbound application interfaces, and simple or complex calling logic can be implemented according to the actual orchestration logic. When zero southbound application interfaces are associated, step S1013 does not depend on step S1012. When multiple southbound application interfaces are associated, step S1013 depends on step S1012.

[0120] The above data consists of structured data processed by providers, southbound application interfaces, consumers, applications, application IP blacklists and whitelists, application authorizations, and application subscriptions.

[0121] The above processing involves converting providers, southbound application interfaces, consumers, applications, application IP blacklists and whitelists, application authorizations, and application subscriptions into structured data.

[0122] The above storage refers to the process of saving structured data, including information on providers, southbound application interfaces, consumers, applications, application IP blacklists and whitelists, application authorizations, and application subscriptions, into a database.

[0123] Step S1011: Process and store the provider data.

[0124] The structured data processed by the provider is stored in a database, where the table structure is shown in Table 3.

[0125] name code Notes Data types id id id char(32) name name name varchar(100) coding code coding varchar(50) Contact number contact_number Contact number varchar(20) host host host varchar(100) port port port int Consumer ID consumer_id Consumer ID char(32)

[0126] Table 3 Provider Table Structure

[0127] In the table structure, id is the primary key of the table, name is the provider's name, code is the provider's unique identifier, contact number is the provider's contact number, host is the hostname of the provider providing the service, port is the port on which the provider provides the service, and consumer id is the primary key of the consumer associated with the provider in the consumer table.

[0128] Step S1012: Process and store the southbound application interface data.

[0129] The structured data processed by the southbound application programming interface is stored in the database, and the table structure in the database is shown in Table 4.

[0130] name code Notes Data types id id id char(32) coding code coding varchar(100) name name name varchar(100) Provider ID provider_id Provider ID char(32) Application Programming Interface Pattern api_schema A JSON string describing the entire application interface. text

[0131] Table 4. Southbound Application Programming Interface Table Structure

[0132] In the table structure, id is the primary key of the table, name is the name of the southbound application interface, code is the unique identifier of the southbound application interface, provider id is the primary key of the provider table for the provider of the current southbound application interface, and application interface mode is the application interface mode of the southbound application interface.

[0133] Step S1013: Process and store the northbound application interface data.

[0134] The structured data processed by the northbound application programming interface is stored in the database, and the table structure in the database is shown in Table 5.

[0135] name code Notes Data types id id id char(32) coding code coding varchar(100) name name name varchar(100) type type Type 1 / Request 2 / Push int state state Status 0 / Disabled 1 / Enabled int TPS threshold tps_threshold There are no restrictions when the TPS threshold is less than 1. int Application Programming Interface Pattern api_schema A JSON string describing the entire application interface. text Scripting script script text Application coding script application_code_script Application coding script text Authentication types authentication_type Authentication types: basic (HTTP basic) and mauth (signature authentication). varchar(100)

[0136] Table 5. Structure of Northbound Application Programming Interface Table

[0137] In the table structure, id is the primary key of the table, code is the unique identifier of the northbound application interface, name is the name of the northbound application interface, type is the type of the northbound application interface, status is the status of the northbound application interface, application interface mode is the application interface mode of the northbound application interface, orchestration script is the orchestration script of the northbound application interface, application encoding script is the script for obtaining the application encoding in the northbound application interface request, and authentication type is the authentication type of the northbound application interface.

[0138] Step S1014: Process and store consumer data.

[0139] The structured data processed by consumers is stored in a database, and the table structure in the database is shown in Table 6.

[0140] name code Notes Data types id id id char(32) name name name varchar(100) type type Type 1 / Individual 2 / Enterprise int address address address varchar(200) Contact number contact_number Contact number varchar(20)

[0141] Table 6 Consumer Table Structure

[0142] In the table structure, id is the primary key of the table, name is the name of the consumer, type is the type of the consumer, address is the contact address of the consumer, and contact number is the contact number of the provider.

[0143] Step S1015: Process and store the application data.

[0144] The structured data processed by the application is stored in the database, and the table structure in the database is shown in Table 7.

[0145] name code Notes Data types id id id char(32) name name name varchar(100) coding code coding varchar(100) password password password varchar(100) state state Status -1 / Abnormal offline / 0 / Disabled / Enabled int Consumer ID consumer_id Consumer ID char(32)

[0146] Table 7 Application Table Structure

[0147] In the table structure, id is the primary key of the table, name is the name of the application, code is the unique identifier of the application, which is used as the username during authentication, password is the password used for application authentication, status is the status of the consumer, and consumer id is the primary key of the consumer associated with the application in the consumer table.

[0148] Step S1016: Process and store the application IP blacklist / whitelist data.

[0149] The structured data for IP blacklist and whitelist processing is stored in a database, and the table structure in the database is shown in Table 8.

[0150] name code Notes Data types id id id char(32) type type Type 1 / Whitelist 2 / Blacklist int host host_name host varchar(200) Application ID application_id Application ID char(32)

[0151] Table 8. Structure of the Application IP Blacklist / Whitelist

[0152] In the table structure, id is the primary key of the table, type is the type of application IP blacklist / whitelist, host is the hostname of the application IP blacklist / whitelist, and application id is the primary key of the application associated with the application IP blacklist / whitelist in the application table.

[0153] Step S1017: Process and store the application authorization data.

[0154] The structured data for application authorization processing is stored in a database, where the table structure is shown in Table 9.

[0155] name code Notes Data types id id id char(32) Application ID application_id Application ID char(32) Northbound Application Programming Interface ID north_api_id Northbound API ID char(32) TPS threshold tps_threshold TPS threshold int

[0156] Table 9 Application Authorization Table Structure

[0157] In the table structure, id is the primary key of the table, application id is the primary key of the application associated with the application authorization in the application table, northbound application interface id is the primary key of the northbound application interface associated with the application authorization in the northbound application interface table, and TPS threshold is the TPS threshold for application authorization to access the northbound application interface.

[0158] Step S1018: Process and store the application subscription data.

[0159] The structured data of the application subscription processing is stored in a database, where the table structure is shown in Table 10.

[0160] name code Notes Data types id id id char(32) Northbound Application Programming Interface ID north_api_id Northbound API ID char(32) Application ID application_id Application ID char(32) Application Programming Interface Pattern api_schema Describe the entire API JSON string text Scripting script script text

[0161] Table 10 Application Subscription Table Structure

[0162] In the table structure, id is the primary key of the table, northbound application interface id is the primary key of the northbound application interface associated with the application subscription in the northbound application interface table, application id is the primary key of the application associated with the application subscription in the application table, application interface pattern is the application interface pattern of the messager application that receives this subscription message, and orchestration script is the orchestration script of the application subscription.

[0163] Step S102: The strategy module receives the HTTP request message sent by the HTTP request client.

[0164] In step S103, the policy module performs access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and traffic control according to the policy.

[0165] The policy module parses the HTTP request message and executes access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and flow control in sequence. If the execution result is to allow access, the HTTP request message is forwarded to the scheduling module, and the subsequent HTTP response message from the scheduling module is forwarded to the HTTP request client. Otherwise, a failed HTTP response message is directly constructed and forwarded to the HTTP request client.

[0166] The specific implementation process of step S103 is as follows: Figure 4 .

[0167] Step S1031: Parse the HTTP request message.

[0168] Step S1032: Perform access authentication.

[0169] Access authentication supports HTTP Basic authentication and signature authentication.

[0170] HTTP Basic authentication first decrypts the value of the Authorization field in the HTTP request header using the HTTP Basic authentication decryption method to obtain the username and password. The username is the code of the application under the consumer, and the password is the password of the application under the consumer. Then, it searches the application table for an application whose code is equal to the username obtained by decryption using the HTTP Basic authentication decryption method. If the application is found and its password matches the password obtained by decryption using the HTTP Basic authentication decryption method, the authentication is considered successful.

[0171] Signature authentication decrypts the value of the Authorization field in the HTTP request header using the signature authentication decryption method, obtaining the username, timestamp, and signature string. The username is the encoding of the application under the consumer, the timestamp is the timestamp of the HTTP request, and the signature string is the signed string. Then, it compares the difference between the timestamp and the timestamp of the time the device received the request to see if it is within a specified error range. If not, authentication fails. If it is, it searches the application table for an application whose encoding equals the username obtained through signature authentication decryption. If found, it uses the username, timestamp, and application password obtained through signature authentication decryption to perform a signature. The resulting string is then compared with the signature obtained through signature authentication decryption; if they match, authentication is considered successful.

[0172] The above HTTP Basic authentication decryption method is one way to decrypt HTTP Basic authentication. The value of the Authorization header field in the HTTP request message begins with "Basic". The username and password are separated by colons and then Base64 encoded. The specific format is: Authorization: Basic {Base64 encoded username and password}. Therefore, the decoding method involves Base64 decoding the Base64 encoded username and password, and then separating the strings according to the colons. The first group is the username, and the second group is the password.

[0173] The above-described signature authentication decryption method is one way to decrypt signature authentication. The value of the Authorization header field in the HTTP request message begins with "Sign". The username, timestamp, and signature string are separated by commas and then Base64 encoded. The specific format is: Authorization: Basic {Base64 encoded username, timestamp, and signature string}. Therefore, the decoding method involves Base64 decoding the Base64 encoded username, timestamp, and signature string, and then separating the strings according to the commas. The first group is the username, the second group is the timestamp, and the third group is the signature string.

[0174] The above signature is a method used in HTTP requests to verify data integrity and authenticate identity. We obtain the signature string by MD5 encoding the username, password, and timestamp.

[0175] Step S1033: Determine whether the authentication is successful. If not, proceed to step S10313; if yes, proceed to step S1034.

[0176] Step S10313: Forward the constructed HTTP response message to the HTTP request client.

[0177] If access is not granted, construct an HTTP response message, fill in the HTTP response status code, and forward it to the HTTP request client. Specifically, if access authentication fails, the HTTP response status code is 401; if IP blacklist / whitelist verification fails, the HTTP response status code is 403; if access resource permission verification fails, the HTTP response status code is 403; if access resource status verification fails, the HTTP response status code is 403; and if flow control fails, the HTTP response status code is 503.

[0178] Step S1034: Perform IP blacklist / whitelist verification.

[0179] The above IP blacklist / whitelist verification first obtains the hostname or domain name to be accessed from the Host header field in the HTTP request message. Then, based on the application obtained in step S1032, it searches the application IP blacklist / whitelist table for all IP blacklists / whitelists whose application ID is equal to the application ID in the IP blacklist / whitelist table, and iterates through them. If a whitelist exists in the type of IP blacklist / whitelist among all IP blacklists / whitelists, it then checks whether the hostname or domain name obtained from the header field is the same as the host in the IP blacklist / whitelist among all IP blacklists / whitelists. If they are the same, the request is allowed; otherwise, it is blocked. If a whitelist does not exist in the type of IP blacklist / whitelist among all IP blacklists / whitelists, it then checks whether the hostname or domain name obtained from the header field is the same as the host in the IP blacklist / whitelist among all IP blacklists / whitelists. If they are the same, the request is blocked; otherwise, the request is allowed.

[0180] Step S1035: Determine whether the blacklist / whitelist verification passes. If not, proceed to step S10313; if yes, proceed to step S1036.

[0181] Step S1036: Perform resource access permission verification.

[0182] Access permission verification first obtains the northbound application interface in the current application interface orchestration and scheduling process, and then obtains the application authorization from the application authorization table that is equal to the northbound application interface ID and the application ID is equal to the application ID obtained according to step S1032. If they exist, the access is granted; otherwise, it is blocked.

[0183] The above-mentioned method obtains the northbound application interfaces in the current application interface orchestration and scheduling process. When starting the HTTP service, this invention retrieves all northbound application interfaces from the northbound application interface table and iterates through them, obtaining the request URI expression of the application interface pattern for each northbound application interface and listening for it. When an HTTP request client accesses the HTTP service, only requests matching the request URI expression of the application interface pattern of the northbound application interface will undergo the application interface orchestration and scheduling process. Therefore, the northbound application interfaces accessed by the current HTTP request client can be obtained throughout the entire application interface orchestration and scheduling process.

[0184] Step S1037: Determine whether the access permission verification passes. If not, proceed to step S10313; if yes, proceed to step S1038.

[0185] Step S1038: Perform resource access status verification.

[0186] Access resource status verification: First, obtain the northbound application interface in the current application interface orchestration and scheduling process, and determine whether the status of the northbound application interface is enabled. If not, block; if so, determine whether the status of the application obtained in step S1032 is enabled. If so, allow; otherwise, block.

[0187] Step S1039: Determine whether the access resource status verification has passed. If not, proceed to step S10313; if yes, proceed to step S10310.

[0188] Step S10310: Perform flow control.

[0189] Flow control is performed by obtaining the TPS threshold for application authorization from step S1036. A token bucket algorithm is used for flow control, and the number of tokens generated per second is set as the TPS threshold for application authorization. Access is granted when a token can be obtained; otherwise, access is blocked.

[0190] The token bucket algorithm is an algorithm used to limit the frequency or traffic of access. It is based on the concept of a token bucket, in which tokens are added to the bucket at a fixed rate. Whenever a request arrives, it needs to obtain a token from the token bucket before it can be processed. If there are not enough tokens in the token bucket, the request may have to wait or be rejected.

[0191] Step S10311: Determine whether the flow control exceeds the threshold. If not, proceed to step S10313; otherwise, proceed to step S10312.

[0192] Step S10312: Forward the HTTP request message to the scheduling module.

[0193] Step S104: The scheduling module performs scheduling according to the scheduling script and generates an HTTP response message.

[0194] Step S104, the specific implementation process is as follows: Figure 5 This describes the process of application interface orchestration during the application interface orchestration and scheduling process. Based on the type of northbound application interface, it can be divided into request process and push process, where step S1043 is the request process, and steps S1044, S1045, S1046, S1047, S1048, and S1049 are the push process.

[0195] The above request process corresponds to the authorization process in three steps between the application, the northbound application programming interface, and the southbound application programming interface, referring to the process of northbound access to southbound applications in the business.

[0196] The above push process corresponds to the subscription process in three steps between the application, the northbound application programming interface, and the southbound application programming interface, referring to the process of the southbound request to the northbound process in the business.

[0197] Step S1041: Obtain the type of the northbound application interface in the current application interface orchestration and scheduling process.

[0198] Step S1042: Determine the type of the northbound application interface. If it is a request, proceed to step S1043; if it is a push, proceed to step S1044.

[0199] Step S1043: Execute the orchestration script in the northbound application programming interface to process the request logic.

[0200] The request logic processing and orchestration scripts handle the request flow and support the general features of orchestration scripts. However, the default object does not support forwarding the application interface context to the application interface received by the consumer's application at the time of subscription. The default object forwarding the application interface context to the southbound application interface provided by the provider can convert the application interface context into an HTTP request message, then forward it to the HTTP response client of the southbound application interface. The HTTP response client returns an HTTP response message, and then generates the application interface context based on the southbound application interface pattern and the HTTP response message, finally returning the application interface context. This default object has no limit on the number of calls.

[0201] The general characteristics of the aforementioned orchestration scripts refer to the fact that the orchestration scripts support the basic features of scripting languages, support calling methods of pre-defined objects, support dynamic updates, and support adding, deleting, and modifying application interface contexts according to the application interface pattern.

[0202] The above-mentioned conversion of the application interface context into an HTTP request message refers to creating an HTTP request message by directly obtaining relevant information from the application interface context and filling it into the HTTP request message.

[0203] The above-mentioned application interface pattern and HTTP response message generation application interface context refer to the HTTP response message being validated through the application interface pattern, and the relevant information defined by the application interface pattern being obtained from the HTTP response message and filled into the application interface context.

[0204] The request logic processing first generates an application interface context based on the application interface mode of the northbound application interface in the current application interface orchestration and scheduling process and the HTTP request message. Then, it processes the request according to the general characteristics of the orchestration script and returns the application interface context. Finally, it generates an HTTP response message based on the application interface mode of the northbound application interface in the current application interface orchestration and scheduling process and the returned application interface context.

[0205] The above-mentioned application interface pattern and HTTP request message generation application interface context refer to the HTTP request message being validated through the application interface pattern, and the relevant information defined by the application interface pattern being obtained from the HTTP request message and filled into the application interface context.

[0206] The above-mentioned application interface pattern and returned application interface context generate an HTTP response message. This means creating an HTTP response message, validating the returned application interface context through the application interface pattern, and obtaining the relevant information defined by the application interface pattern from the returned application interface context to fill in the HTTP response message.

[0207] Request logic processing can generally be divided into direct callback mode, proxy mode, and mixed mode based on logical distinctions.

[0208] The direct callback pattern described above involves the consumer application calling the northbound application programming interface (API) but not the southbound API. This is typically used for functions that can be performed directly by the system itself, such as retrieving server time. Figure 6 .

[0209] The above proxy pattern involves a consumer application calling a northbound application programming interface (API) and forwarding the call to a southbound API. This pattern is used in most scenarios, such as... Figure 7 .

[0210] The aforementioned mixed-language mode involves the consumer application calling a northbound application programming interface (API), forwarding the request to multiple southbound APIs, and executing scripts based on the HTTP response messages from the southbound APIs. This mode can handle complex processing requirements, such as... Figure 8 .

[0211] Step S1044: Execute the application coding script in the northbound application programming interface to obtain the push application.

[0212] The above application encoding script obtains the push application and application encoding, and supports the general features of orchestration scripts. However, the default object does not support forwarding the application interface context to the southbound application interface provided by the provider and forwarding the application interface context to the application interface received by the consumer's application when subscribing.

[0213] The application encoding script retrieves the push application. First, it generates an application interface context based on the application interface mode and HTTP request message of the northbound application interface in the current application interface orchestration and scheduling process. Then, it processes the application according to the general characteristics of the application encoding script and returns the push application code. Finally, it searches the application table for an application whose code is equal to the push application code.

[0214] Step S1045: Determine whether the push application can be obtained. If not, proceed to step S1049; if yes, proceed to step S1046.

[0215] Step S1049: Forward the constructed HTTP response message to the HTTP request client.

[0216] If the push application is not obtained or the application subscription is not obtained, construct an HTTP response message, fill in the HTTP response status code, and forward it to the HTTP request client. Specifically, if the push application is not obtained, the HTTP response status code is 404; if the application subscription is not obtained, the HTTP response status code is 403.

[0217] Step S1046: Obtain application subscriptions based on push applications and northbound application interfaces.

[0218] Specifically, the application subscription is obtained from the application subscription table where the application ID is equal to the application ID obtained in step S1044 and the northbound application interface ID is equal to the application subscription where the northbound application interface ID is obtained in the current application interface orchestration and scheduling process.

[0219] Step S1047: Determine whether an application subscription can be obtained. If not, proceed to step S1049; if yes, proceed to step S1048.

[0220] Step S1048: Execute the orchestration script in the application subscription to perform push logic processing and obtain the HTTP response message.

[0221] The above push logic processing, with orchestration scripts supporting the general features of orchestration scripts for push flow processing, does not support forwarding the application interface context to the southbound application interface provided by the provider in the pre-defined object. Specifically, the pre-defined object forwarding the application interface context to the application interface received by the consumer's application at the time of subscription can convert the application interface context into an HTTP request message, and then forward it to the HTTP response client of the application interface received by the consumer's application at the time of subscription. The HTTP response client returns an HTTP response message, and then generates the application interface context based on the application interface pattern in the application subscription and the HTTP response message, and returns the application interface context. This pre-defined object can only be called once.

[0222] The push logic processing first generates an application interface context based on the application interface mode and HTTP request message of the northbound application interface in the current application interface orchestration and scheduling process. Then, it processes the application interface context according to the general characteristics of the orchestration script and returns the application interface context. Finally, it generates an HTTP response message based on the application interface mode in the application subscription and the returned application interface context.

[0223] In step S105, the scheduling module sends the HTTP response message to the HTTP request client. Example

[0224] This invention is based on an HTTP message dynamic orchestration device, including:

[0225] Configuration module: processes and stores data;

[0226] Policy module: Receives HTTP request messages sent by HTTP request clients and performs access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and flow control according to the policy.

[0227] Scheduling module: It performs scheduling according to the scheduling script and generates HTTP response messages, and sends the HTTP response messages to the HTTP request client.

[0228] The key points of the method of this invention are as follows:

[0229] 1. The design and implementation of the business model: The business model abstracts the various business entities in the access process and defines the authorization and subscription processes, allowing the device of this invention to be easily inserted into existing platforms. For example, a platform may have two application programming interfaces (APIs): API 1 is an external call to the platform, and the platform does not provide authentication; API 2 is a platform call to the external entity. In this case, the device of this invention defines the external entity as the consumer, the platform as the provider, and defines three APIs: Southbound API 1 is API 1, Northbound API 1 is a Southbound API 1 arranged in a transparent mode, and Northbound API 2 is API 2. The consumer authorizes Northbound API 1 and subscribes to Northbound API 2. When the consumer calls the Northbound API, it will be protected by the authentication provided by this invention. Refer to step S101 for the relevant description of the business model.

[0230] 2. The design and implementation of the Application Programming Interface (API) model: The API pattern abstracts the HTTP API, constraining its details in the model. For example, it defines the parameters in an API request and their types, as well as the parameters and types in the API response. The API context abstracts a specific HTTP API call, reflecting its details in the model, such as the specific values ​​of the request and response parameters. This decouples the HTTP protocol from the code and framework, making the API independent of specific frameworks. For instance, if the Spring framework is used to receive HTTP request messages, but an HTTP client is used to send them, these two frameworks may have different HTTP input and output parameters, making direct adaptation impossible. Decoupling allows for convenient use of the API model to pass API-related information across different code frameworks. Refer to step S101 for the description of the business model.

[0231] 3. The design and implementation of the application interface orchestration and scheduling process combines the application interface model and the business model to orchestrate the application interface, and provides direct response mode, pass-through mode and mixed mode in request logic processing, making the access of application interfaces more flexible. Refer to steps S102, S103, S104 and S105.

[0232] The advantages of this invention are as follows:

[0233] 1. The method of this invention aims to protect point 1, which can realize the integrated management and control of various application interfaces for northbound requests to southbound and southbound requests to northbound without modifying the existing platform, and make the business process clearly reflected in this invention.

[0234] 2. The method of this invention aims to protect point 2 by abstracting the application programming interface (API), allowing it to be used in different code frameworks to transmit API-related information, thus greatly simplifying the integration cost of cross-language and cross-framework APIs.

[0235] 3. The method of this invention aims to protect point 3 by using an application programming interface (API) to orchestrate the scheduling process, allowing the API to implement more control logic without code modification. For example, each of the mobile, China Unicom, and China Telecom platforms has an interface for querying whether a number within the network is registered. In this case, an interface needs to be provided for external calls. The processing logic of this interface is to automatically determine which operator the number belongs to and automatically call the APIs of different operators for querying whether a number within the network is registered. The traditional approach involves code development, adaptation, testing, release, and upgrades, which is a lengthy process. However, using the device of this invention, only a northbound application programming interface needs to be defined. The orchestration script determines which operator the first three digits of the number segment belong to and then forwards the request to the corresponding operator's API for querying whether a number within the network is registered. This orchestration script is dynamically updated, and its speed and efficiency far surpass those of the traditional method.

[0236] 4. The method of this invention aims to protect point 4, which, after the platform integrates this invention, provides access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and traffic control. No code development is required, significantly improving integration efficiency.

[0237] Note:

[0238] A URI (Uniform Resource Identifier) ​​is an important component of an HTTP request, used to identify and locate resources.

[0239] HTTP (Hypertext Transfer Protocol) is an application-layer protocol used for transmitting hypertext.

[0240] IP (Internet Protocol) is a network protocol used on the Internet for transmitting data packets. The IP protocol defines the communication rules and address allocation methods between network devices.

[0241] Base64 is an encoding method used to convert binary data into printable ASCII characters.

[0242] TPS stands for "Transactions Per Second," and it's a metric for measuring the processing capacity of a system, application, or service. TPS represents the number of transactions or requests a system can process in one second.

[0243] JSON is a lightweight data-interchange format, short for JavaScript Object Notation.

[0244] AES is an abbreviation for Advanced Encryption Standard, a symmetric encryption algorithm.

[0245] DES is an abbreviation for Data Encryption Standard, a symmetric encryption algorithm.

[0246] MD5 is the fifth version of the Message Digest Algorithm, and it is a commonly used hash function algorithm.

[0247] A UUID (Universally Unique Identifier) ​​is an identifier used to uniquely identify an entity or resource in a computer system.

[0248] NFV (Network Function Virtualization) is a network function virtualization technology designed to decouple the functions of traditional dedicated network devices (such as routers and firewalls) from hardware and transfer them to general-purpose servers, storage, and network devices, thereby improving network flexibility, scalability, and cost-effectiveness.

[0249] IT (Information Technology) refers to information technology, a set of technologies and tools widely used in various fields for processing, storing, transmitting, and managing information.

[0250] Software-Defined Networking (SDN) is a network architecture and technology that separates the network control plane from the data forwarding plane, enabling centralized management and control of the network in software.

[0251] IMS (IP Multimedia Subsystem) is a multimedia communication system architecture based on IP networks.

[0252] IVR is an abbreviation for Interactive Voice Response. It is an automated telephone system that interacts with users through voice and keypad input, providing functions such as self-service and information retrieval.

[0253] QoS is an abbreviation for Quality of Service. It refers to a mechanism in computer networks for managing and optimizing network resources to meet specific performance requirements and service levels.

Claims

1. A method for dynamically orchestrating HTTP messages, characterized in that... Includes the following steps: Step S101: The configuration module processes and stores the data; Step S102: The strategy module receives the HTTP request message sent by the HTTP request client; In step S103, the policy module performs access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and traffic control according to the policy. Step S104: The scheduling module performs orchestration according to the orchestration script and generates an HTTP response message; Step S105: The scheduling module sends the HTTP response message to the HTTP request client; The implementation process of step S103 is as follows: Step S1031: Parse the HTTP request message; Step S1032: Perform access authentication. Access authentication supports HTTP Basic authentication and signature authentication. Step S1033: Determine whether the authentication is successful. If not, proceed to step S10313; if yes, proceed to step S1034. Step S1034: Perform IP blacklist / whitelist verification. The IP blacklist / whitelist verification first obtains the hostname or domain name to be accessed from the Host header field in the HTTP request message. Then, based on the application obtained in step S1032, it searches the application IP blacklist / whitelist table for all IP blacklists / whitelists whose application ID is equal to the application ID in the IP blacklist / whitelist table, and iterates through them. If the type of IP blacklist / whitelist in all IP blacklists / whitelists is a whitelist, it then checks whether the hostname or domain name obtained from the header field is the same as the host in the IP blacklist / whitelist in all IP blacklists / whitelists. If they are the same, the request is allowed; otherwise, it is blocked. If the type of IP blacklist / whitelist in all IP blacklists / whitelists is not a whitelist, it then checks whether the hostname or domain name obtained from the header field is the same as the host in the IP blacklist / whitelist in all IP blacklists / whitelists. If they are the same, the request is blocked; otherwise, the request is allowed. Step S1035: Determine whether the blacklist / whitelist verification passes. If not, proceed to step S10313; otherwise, proceed to step S1036. Step S1036: Perform resource access permission verification. The access resource permission verification first obtains the northbound application interface in the current application interface orchestration and scheduling process, and then obtains the application authorization from the application authorization table that is equal to the northbound application interface ID and the application ID is equal to the application ID obtained according to step S1032. If they exist, the access is allowed; otherwise, it is blocked. The process of obtaining the northbound application interfaces in the current application interface orchestration and scheduling process involves retrieving all northbound application interfaces from the northbound application interface table and traversing it when starting the HTTP service. The request URI expression of the application interface pattern of the northbound application interface is then listened for. When an HTTP request client accesses the HTTP service, only requests that match the request URI expression of the application interface pattern of the northbound application interface will undergo the application interface orchestration and scheduling process. Therefore, the northbound application interfaces accessed by the current HTTP request client can be obtained throughout the entire application interface orchestration and scheduling process. Step S1037: Determine whether the access permission verification passes. If not, proceed to step S10313; otherwise, proceed to step S1038. Step S1038: Perform resource access status verification. The access resource status verification first obtains the northbound application interface in the current application interface orchestration and scheduling process, and determines whether the status of the northbound application interface is enabled. If not, it is blocked. If it is, it determines whether the status of the application obtained according to step S1032 is enabled. If it is, it is allowed; otherwise, it is blocked. Step S1039: Determine whether the access resource status verification passes. If not, proceed to step S10313; otherwise, proceed to step S10310. Step S10310: Perform flow control. The flow control process involves obtaining the application authorization TPS threshold from step S1036, using the token bucket algorithm for flow control, and setting the number of tokens generated per second as the application authorization TPS threshold. When a token can be obtained, the flow is allowed; otherwise, it is blocked. Step S10311: Determine whether the flow control exceeds the threshold. If not, proceed to step S10313; otherwise, proceed to step S10312. Step S10312: Forward the HTTP request message to the scheduling module; Step S10313: Forward the constructed HTTP response message to the HTTP request client. In the case of non-allowing, construct an HTTP response message, fill in the HTTP response status code, and forward it to the HTTP request client. When access authentication fails, the HTTP response status code should be 401; when IP blacklist / whitelist verification fails, the HTTP response status code should be 403; when access resource permission verification fails, the HTTP response status code should be 403; when access resource status verification fails, the HTTP response status code should be 403; and when flow control fails, the HTTP response status code should be 503.

2. The HTTP message dynamic orchestration method according to claim 1, characterized in that... Step S101 is independent of the application interface orchestration and scheduling process. It mainly processes and stores the data required for the execution of steps S102, S103, S104, and S105 based on the business model. The application interface orchestration, or orchestration for short, refers to the process of combining and executing multiple application interface requests in a specific order using an application interface model and an orchestration script to achieve more complex business logic or functions. The application interface model includes an application interface pattern and an application interface context. The application interface pattern expresses the constraints of the application interface, while the application interface context expresses the specific information of a particular access to the application interface. The application interface pattern is a description of the application interface, and the application interface context is the specific carrier of the application interface.

3. The HTTP message dynamic orchestration method according to claim 2, characterized in that... The orchestration script is a scripting language. In addition to supporting the basic features of scripting languages, it also supports calling methods of pre-defined objects, supports dynamic updates, and supports adding, deleting, and modifying the application interface context according to the application interface pattern. The preset object is a set of predefined operations in the main language that calls the orchestration script, wherein the operations of the preset object can be extended and supported; The dynamic update refers to the ability to update the orchestration script without restarting the device when the script changes.

4. The HTTP message dynamic orchestration method according to claim 2, characterized in that... The business model serves as the business foundation, used to constrain and abstract the business aspects of HTTP access clients, HTTP response clients, and HTTP application programming interfaces, and to provide business information support for strategies and orchestration engines. The HTTP access client and HTTP response client are abstracted into business logic, with the HTTP access client being abstracted as a consumer and the HTTP response client being abstracted as a provider. HTTP application programming interfaces (APIs) are categorized into northbound APIs and southbound APIs based on different levels. Northbound APIs are APIs called by consumers, while southbound APIs are APIs provided by providers.

5. The HTTP message dynamic orchestration method according to claim 1, characterized in that... The implementation process of step S101 is as follows: Step S1011: Process and store the provider data, and store the structured data processed by the provider into the database; Step S1012: Process and store the southbound application interface data, and store the structured data processed by the southbound application interface into the database; Step S1013: Process and store the northbound application interface data, and store the structured data processed by the northbound application interface into the database; Step S1014: Process and store consumer data, storing the structured data processed by consumers into the database; Step S1015: Process and store the application data, and store the structured data processed by the application into the database; Step S1016: Process and store the application IP blacklist and whitelist data, and store the structured data of the application IP blacklist and whitelist processing into the database; Step S1017: Process and store the application authorization data, and store the structured data of the application authorization processing into the database; Step S1018: Process and store the application subscription data, and store the structured data of the application subscription processing into the database.

6. The HTTP message dynamic orchestration method according to claim 5, characterized in that... Step S1014 depends on step S1011, and step S1013 depends on step S1012 in some cases. After step S1015, steps S1016, S1017, and S1018 are three processes that can be performed simultaneously, and there is no order among them. Step S1013 depends on step S1012 in some cases. This means that the northbound application interface can be associated with zero or more southbound application interfaces, and simple or complex calling logic can be implemented according to the actual orchestration logic. When zero southbound application interfaces are associated, step S1013 does not depend on step S1012. When multiple southbound application interfaces are associated, step S1013 depends on step S1012.

7. The HTTP message dynamic orchestration method according to claim 1, characterized in that... The HTTP Basic authentication first decrypts the value of the Authorization field in the HTTP request message header using the HTTP Basic authentication decryption method to obtain the username and password. The username is the code of the application under the consumer, and the password is the password of the application under the consumer. Then, it searches the application table for an application whose code is equal to the username obtained by decryption using the HTTP Basic authentication decryption method. If the application is found and its password matches the password obtained by decryption using the HTTP Basic authentication decryption method, the authentication is considered successful. The signature authentication process decrypts the value of the Authorization field in the HTTP request header using a signature authentication decryption method to obtain the username, timestamp, and signature string. The username is the code of the application under the consumer, the timestamp is the timestamp of the HTTP request, and the signature string is the signed string. Then, the difference between the timestamp and the timestamp of the time the device received the request is compared to see if it is within a specified error range. If not, authentication fails. If it is, the application table is searched for an application whose code equals the username obtained through signature authentication decryption. If found, the username, timestamp, and application password obtained through signature authentication decryption are used to create a signature. The resulting string is then compared with the signature obtained through signature authentication decryption; if they match, authentication is considered successful.

8. The HTTP message dynamic orchestration method according to claim 1, characterized in that... The implementation process of step S104 is as follows: Step S1041: Obtain the type of the northbound application interface in the current application interface orchestration and scheduling process; Step S1042: Determine the type of the northbound application interface. If it is a request, proceed to step S1043; if it is a push, proceed to step S1044. Step S1043: Execute the orchestration script in the northbound application programming interface to process the request logic. The request logic processing, the orchestration script for the request flow processing, supports the general features of the orchestration script, but the default object does not support forwarding the application interface context to the application interface received by the consumer's application when subscribing. The pre-defined object forwards the application interface context to the southbound application interface provided by the provider. It can convert the application interface context into an HTTP request message and then forward it to the HTTP response client of the southbound application interface. The HTTP response client returns an HTTP response message, and then generates the application interface context according to the southbound application interface mode and the HTTP response message. Finally, it returns the application interface context. This pre-defined object does not limit the number of times it can be called. Step S1044: Execute the application coding script in the northbound application programming interface to obtain the push application. The application encoding script obtains the push application by first generating an application interface context based on the application interface mode and HTTP request message of the northbound application interface in the current application interface orchestration and scheduling process, then processing it according to the general characteristics of the application encoding script, returning the push application code, and finally searching for the application whose code is equal to the push application code from the application table. Step S1045: Determine whether the push application can be obtained. If not, proceed to step S1049; if yes, proceed to step S1046. Step S1046: Obtain application subscriptions based on push applications and northbound application interfaces; Step S1047: Determine whether an application subscription can be obtained. If not, proceed to step S1049; if yes, proceed to step S1048. Step S1048: Execute the orchestration script in the application subscription to perform push logic processing and obtain the HTTP response message. The push logic processing first generates an application interface context based on the application interface mode and HTTP request message of the northbound application interface in the current application interface orchestration and scheduling process. Then, it processes the application interface context according to the general characteristics of the orchestration script and returns the application interface context. Finally, it generates an HTTP response message based on the application interface mode in the application subscription and the returned application interface context. Step S1049: Forward the constructed HTTP response message to the HTTP request client. If the push application and application subscription are not obtained, construct the HTTP response message, fill in the HTTP response status code, and forward it to the HTTP request client. If the push application is not received, the HTTP response status code should be 404; if the application subscription is not received, the HTTP response status code should be 403.

9. An apparatus for use in the HTTP message dynamic orchestration method according to claim 1, characterized in that... include: Configuration module: processes and stores data; Policy module: Receives HTTP request messages sent by HTTP request clients and performs access authentication, IP blacklist / whitelist verification, access resource permission verification, access resource status verification, and flow control according to the policy. Scheduling module: It performs scheduling according to the scheduling script and generates HTTP response messages, and sends the HTTP response messages to the HTTP request client.

Images