Service Request Processing Method and Device

Abstract

The present invention discloses a service request processing method and apparatus, relating to the field of network technologies; the service request processing method includes: creating a corresponding relationship between a pre-configured connector and an interface provider, where the connector is used to initiate an authentication request to the interface provider and forward a request message generated when a client initiates a restful request to the interface provider to the interface provider; receiving the request message, and sending the request message to the connector according to the corresponding relationship; initiating an authentication request to the interface provider through the connector, and after the authentication request is passed, forwarding the request message to the interface provider through the connector; the present invention solves the problem that different authentication methods need to be performed by users for different third-party service platforms.

Description

Technical Field

[0001] The present invention relates to the field of network technologies, and in particular, to a service request processing method and apparatus. Background Art

[0002] REST (representational state transfer) is a software architecture style that provides a set of design principles and constraints. RESTful refers to an application or design that meets these constraints and principles. An application programming interface (API) encapsulated using REST principles is called a RESTful API interface. A client can send a RESTful request to the RESTful API interface to obtain an interface request. Since RESTful APIs are simple and easy to use, they are widely used in many network software. RESTful interfaces run over the network, and the authentication problem of securing them has been widely concerned.

[0003] Currently, when invoking services from a third-party service platform, the service authentication method is usually limited to the RESTful API interface of a specific third-party service platform. However, for some enterprise-internal customized third-party service platforms, due to the differences in the authentication forms of the RESTful API interfaces of different third-party service platforms, users need to perform different authentication methods for different third-party service platforms, which is cumbersome to operate, difficult to achieve flexible management of different third-party service platforms, and reduces the user experience of using the RESTful API interface. Summary of the Invention

[0004] The main objective of the present invention is to provide a service request processing method and apparatus to solve the problem in the background art that users need to perform different authentication methods for different third-party service platforms.

[0005] According to one aspect of the present application, a service request processing method is provided, including:

[0006] Create a corresponding relationship between a pre-configured connector and an interface provider, where the connector is used to initiate an authentication request to the interface provider and forward a request message generated when a client initiates a RESTful request to the interface provider to the interface provider;

[0007] Receive the request message and send the request message to the connector according to the corresponding relationship;

[0008] Initiate the authentication request to the interface providing end through the connector, and forward the request message to the interface providing end through the connector after the authentication request is passed.

[0009] Further, before creating the correspondence between the pre-configured connector and the interface providing end, the method includes:

[0010] Obtain the interface document of the interface providing end to configure the connector according to the interface document, where the interface document includes interaction information and authentication information;

[0011] Wherein, the interaction information is used to describe the information required for the client to interact with the interface providing end, so that the connector can send the request message to the interface providing end based on the interaction information, and,

[0012] The authentication information includes the authentication rules for the interface providing end to authenticate the service request initiated by the client and the secret key required for authentication based on the authentication rules, so that the connector can initiate the authentication request to the interface providing end based on the authentication information.

[0013] Further, the step of obtaining the interface document of the interface providing end to configure the connector according to the interface document includes:

[0014] Determine the configuration items required to form the connector, where the configuration items include a first configuration item and a second configuration item, the first configuration item is used to describe the interaction information, and the second configuration item is used to describe the authentication information;

[0015] Parse out the interaction information and the authentication information in the interface document, and inject the interaction information into the first configuration item and inject the authentication information into the second configuration item to obtain the resource file package required to form the connector;

[0016] Load the resource file package to obtain the connector and instantiate the connector.

[0017] Further, the step of loading the resource file package to obtain the connector includes:

[0018] Perform hot loading on the resource file package using a class loader.

[0019] Further, the step of obtaining the interface document of the interface providing end to configure the connector according to the interface document includes:

[0020] Adopt a service discovery mechanism to obtain the interface document, and configure the connector according to the interface document through the service discovery mechanism.

[0021] Further, the step of sending the request message to the connector according to the corresponding relationship includes:

[0022] Determine the syntax format of the development language supported by the interface provider end, and based on the syntax format of the development language, convert the request message into a first message content, and send the first message content to the connector, so that the connector forwards the first message content to the interface provider end.

[0023] Further, the request message is a message in JSON data format. Before converting the request message into a first message content based on the syntax format of the development language, the method further includes:

[0024] Determine the request characteristics of the request message. The content of the request characteristics includes a first field name and a first field value belonging to the first field name. The types of the request characteristics include at least one of a request header, a request path, a request parameter, a body field, and a cookie field;

[0025] After splitting the content of the request characteristics according to a first splitting rule, obtain a first intermediate state message content. The first splitting rule includes a rule of splitting into multiple lines according to different first field names, and / or a rule of splitting multiple different first field values belonging to the same first field name into multiple lines;

[0026] Convert the first intermediate state message content into the first message content based on the syntax format of the development language.

[0027] Further, the development language includes JSON Path, which is a language used for querying in JSON data. The step of converting the first intermediate state message content into a first message content based on the syntax format of the development language includes:

[0028] Adjust the first intermediate state message content according to the syntax format of the JSON Path to obtain the first message content.

[0029] Further, when the request characteristic includes the request path, before obtaining the first intermediate state message content by splitting the content of the request characteristic according to the first splitting rule, the method further includes:

[0030] Parse out the path parameters configured by the client in the request path. The path parameters are the parameters required for the connector to route to the target service interface of the interface provider end;

[0031] Configure the path parameter into the first configuration item, so that the connector invokes the target service interface based on the first configuration item and forwards the request message to the target service interface.

[0032] Further, after forwarding the request message to the interface provider through the connector, the method further includes:

[0033] Receive, through the connector, a return message generated by the interface provider in response to the request message;

[0034] Determine the return characteristics of the return message, and adjust the return characteristics according to the predetermined return characteristics pre-specified by the client until the content of the return characteristics is consistent with the predetermined return characteristics, where the return characteristics include at least one of a response header, a response body, and a Cookie. Then, send the return message to the client.

[0035] Further, the content of the return characteristics is a message content in JSON data format, the content of the return characteristics includes a second field name and a second field value belonging to the second field name, and the content of the predetermined return characteristics includes a predetermined field name and a predetermined field value belonging to the predetermined field name. The step of adjusting the content of the return characteristics according to the predetermined return characteristics pre-specified by the client until the content of the return characteristics is consistent with the predetermined return characteristics includes:

[0036] Split the content of the return characteristics according to a second splitting rule to obtain a second intermediate state message content, where the second splitting rule includes a rule of splitting into multiple lines according to different second field names, and / or a rule of splitting multiple different second field values belonging to the same second field name into multiple lines;

[0037] Judge whether the second field value of the second field name with the same name as the predetermined field name is the same as the predetermined field value. If not, adjust the second field value to the predetermined field value, and / or judge whether there is a second field name in the second intermediate state message content that does not exist in the predetermined return characteristics. If so, delete the second field name and its second field value from the second intermediate state message content;

[0038] After converting the second intermediate state message content into a second message content according to the data exchange format supported by the client, send the second message content as the return message to the client.

[0039] On the other hand, the present application also provides a service request processing device, which is characterized by including:

[0040] A service connection module, which is used to create a corresponding relationship between a pre-configured connector and an interface provider. The connector is used to initiate an authentication request to the interface provider and forward a request message generated when a client initiates a RESTful request to the interface provider to the interface provider;

[0041] A service gateway, which is used to receive the request message and send the request message to the connector through the service connection module according to the corresponding relationship;

[0042] The service connection module is further used to initiate the authentication request to the interface provider through the connector, and after the authentication request passes, forward the request message to the interface provider through the connector.

[0043] The service request processing method provided by the present invention, after creating the corresponding relationship between the connector and the interface provider, can send the received request message to the connector according to the corresponding relationship, so as to initiate an authentication request to the interface provider through the connector, and after the authentication request passes, forward the request message to the interface provider through the connector. That is to say, in the present invention, the client does not need to initiate an authentication request related to service authentication to the third-party service platform serving as the interface provider, but after initiating a RESTful request, initiates an authentication request to the interface provider through the connector. After the interface provider to which the client initiates the RESTful request changes, it can also flexibly find the connector corresponding to the interface provider according to the created corresponding relationship, so as to use the corresponding connector to replace the client to implement the corresponding authentication request and forwarding of the request message, and can implement the authentication methods and requirements of any third-party service platform through the configured connector, realizing flexible management of different third-party service platforms and improving the user experience of the client and the interface provider. Description of the Drawings

[0044] The drawings described herein are used to provide a further understanding of the present application, form a part of the present application, and the illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation to the present application. In the drawings:

[0045] Figure 1 It is a schematic flowchart of a service request processing method provided by an embodiment of the present invention;

[0046] Figure 2 It is a schematic flowchart of configuring a connector provided by an embodiment of the present invention;

[0047] Figure 3 It is a schematic flowchart of converting a request message into a first message content provided by an embodiment of the present invention;

[0048] Figure 4 Schematic diagram of the process of configuring path parameters for the first configuration item of a connector provided by an embodiment of the present invention;

[0049] Figure 5 Schematic diagram of the process of a connector returning a response message to a client provided by an embodiment of the present invention;

[0050] Figure 6 is Figure 5 Specific execution steps of step S52 in

[0051] Figure 7 Interaction schematic diagram among a service request processing device, a client, and an interface provider provided by an embodiment of the present invention. Specific embodiments

[0052] It should be noted that, without conflict, the embodiments in the present application and the features in the embodiments may be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0053] In the prior art, when a user invokes the interface service of a third-party service platform through a client, first, an authentication request related to service authentication needs to be initiated from the client to the third-party service platform, so that the third-party service platform can perform legality or permission authentication on the service request initiated by the client. However, for different third-party service platforms, users often need to perform different authentication methods. In view of this, the first embodiment of the present invention provides a service request processing method. Please refer to Figure 1 which includes the following method steps:

[0054] Step S11: Create a corresponding relationship between a pre-configured connector and an interface provider. The connector is used to initiate an authentication request to the interface provider and forward the request message generated when the client initiates a RESTful request to the interface provider to the interface provider. The interface provider in this embodiment is a third-party service platform that can provide RESTful API interfaces, and the third-party service platform includes at least one of common service platforms in the market, enterprise-customized service platforms, etc.

[0055] Step S12: Receive the request message and send the request message to the connector according to the corresponding relationship;

[0056] Step S13: Initiate an authentication request to the interface provider through the connector, and after the authentication request passes, forward the request message to the interface provider through the connector.

[0057] Accordingly, in this embodiment, corresponding connectors are configured for different interface providers. When the subsequent client initiates a restful request to any interface provider, it only needs to call the connector corresponding to the interface provider to perform the authentication request and forward the request message, eliminating the operation of the client performing the authentication request for different interface providers, making the client unaware of the authorization authentication process, thereby improving the user experience of the client and the interface provider.

[0058] It can be seen that for the service request processing method provided in this embodiment, after establishing the corresponding relationship between the connector and the interface provider, the received request message can be sent to the connector according to the corresponding relationship, so as to initiate an authentication request to the interface provider through the connector, and after the authentication request is passed, forward the request message to the interface provider through the connector. That is to say, in this embodiment, the client does not need to send an authentication request related to service authorization to the third-party service platform acting as the interface provider, but after initiating a restful request, initiates an authentication request to the interface provider through the connector. After the interface provider for which the client initiates the restful request changes, it can also flexibly find the connector corresponding to the interface provider according to the established corresponding relationship, so as to use the corresponding connector to replace the client to implement the corresponding authentication request and request message forwarding, and can implement the authentication methods and requirements of any third-party service platform through the configured connector, realizing flexible management of different third-party service platforms and improving the user experience of the client and the interface provider.

[0059] The connector can forward the request message to the interface provider through the request Proxy. The proxy Proxy, also known as a network proxy, is a special network service that allows a network terminal (usually a client) to connect indirectly to another network terminal (usually a server) through this service. Some network devices such as gateways and routers have the network proxy function. Generally, it is considered that the proxy service is beneficial to protecting the privacy or security of network terminals and preventing attacks. Therefore, in this embodiment, the connector forwards the client's request message to the interface provider (such as a third-party service platform, a server, etc.) through the Proxy and can return the response of the interface provider to the client, which can protect the privacy and security of the connector and prevent attacks.

[0060] Before creating the correspondence between the pre-configured connector and the interface provider end in step S11, the method provided in this embodiment includes the following steps: obtaining the interface document of the interface provider end to configure the connector according to the interface document, where the interface document includes interaction information and authentication information. The interaction information is used to describe the information required for the client to interact with the interface provider end, so that the connector can send a request message to the interface provider end based on the interaction information. The authentication information includes the authentication rule for the interface provider end to authenticate the service request initiated by the client and the key required for authentication based on the authentication rule, so that the connector can initiate an authentication request to the interface provider end based on the authentication information. The interaction information may specifically include the request protocol type, the root path of the requested service, and the fixed service prefix CONTEXT of the requested service. The request protocol type is used to indicate the protocol used by the connector to communicate with the target service, and the request protocol type can be HTTP, HTTPS, etc. The root path is the basic access address of the target service, and all service requests are based on this address. These interaction information can ensure that the connector communicates with the interface provider end correctly and securely. The authentication rule in the authentication information describes how to verify the legality of the restful request. The authentication rule can be not only common basic authentication (Basic Auth), API key, Token authentication, Digest authentication (summary authentication), OAuth authentication, etc., but also other authentication rules for the interface provider end customized for different enterprises.

[0061] Thus, for the connector configured according to the interface document in this embodiment, no matter what authentication rule the interface provider end adopts, when the client initiates a restful request to the corresponding interface provider end, the configured connector corresponding to the requested interface provider end can initiate an authentication request to the interface provider end based on the authentication information. This authentication request process does not require the client to execute and participate, and can flexibly manage interface provider ends with different authentication rules, improving the user's operation convenience and the usage experience of the interface provider end.

[0062] Among them, please refer to Figure 2 , the steps of obtaining the interface document of the interface provider end to configure the connector according to the interface document include the following method steps:

[0063] Step S21: Determine the configuration items required to form the connector. The configuration items include the first configuration item and the second configuration item. The first configuration item is used to describe the interaction information, and the second configuration item is used to describe the authentication information.

[0064] Step S22: Parse out the interaction information and authentication information in the interface document, and inject the interaction information into the first configuration item and the authentication information into the second configuration item to obtain the resource file package required to form the connector.

[0065] Step S23: Load the resource file package to obtain a connector and instantiate the connector. The main purpose of instantiating the connector is to convert the loaded connector class into a specific object. When a client later sends a restful request to the interface provider corresponding to this connector, the corresponding connector object can be operated and used at any time.

[0066] Thus, in this embodiment, after determining the configuration items required for the connector, the interaction information and authentication information in the parsed interface document are configured and injected into the corresponding configuration items to obtain the original resource file package of the connector. Subsequently, only by loading this resource file package and instantiating it can the authentication request and request message forwarding services be provided for the client.

[0067] When the interaction information and authentication information in the interface document are configured and injected into the corresponding configuration items in this embodiment, the request protocol type, root path, etc. of the interaction information need to be injected into the first configuration item so that the connector can forward the request message to the interface provider according to the information in the first configuration item, and the authentication rule and key of the authentication information are injected into the second configuration item so that the connector can perform the operation of the authentication request according to the information in the second configuration item. By directly configuring and injecting the corresponding information into the corresponding configuration items in this embodiment, it can be ensured that the connector dynamically obtains and uses the corresponding information during operation, without the need to hard-code the interaction information and authentication information, improving the flexibility of the connector to adapt to different environments and requirements. Secondly, it is also convenient for the modification and maintenance of the corresponding information. When the information such as the address and port of the target interface provider changes, only the information in the corresponding configuration item in the resource file package needs to be modified, without modifying the code.

[0068] In step S23, the steps of loading the resource file package to obtain the connector include: performing hot loading on the resource file package using a class loader. Hot loading is a mechanism widely used in software development and operation and maintenance. It allows developers to update or replace code, data, or configuration files without interrupting the running of the application. This technology greatly improves the efficiency of development and debugging because it avoids the cumbersome process of restarting the application every time the code is modified. The class loader is responsible for loading the.class file of the class into the Java virtual machine. Hot loading enables the changed code to take effect immediately by reloading the class file at runtime. Thus, in this embodiment, hot loading is performed on the resource file package. Subsequently, as long as the resource file package of the corresponding configured interface provider is obtained, the corresponding connector can be obtained and used in real time, and then the corresponding authentication request, request message forwarding, etc. operations can be performed through the connector. When this service request processing method is executed by the service request processing device, the service request processing device can obtain the corresponding connector in real time without restarting the service.

[0069] In this embodiment, the steps of obtaining the interface document of the interface provider end to configure the connector according to the interface document may specifically include: obtaining the interface document by using a service discovery mechanism, and configuring the connector according to the interface document through the service discovery mechanism. The service discovery mechanism (fully named Service Provider Interface, abbreviated as SPI) allows an application to dynamically load and discover providers (such as the interface provider end that provides the interface document in this embodiment) at runtime and interact with them, realizing the decoupling of the application and the service provider. SPI is very suitable for the development of connectors as plugins, improving the dynamic configuration and usage efficiency of connectors. Specifically, when using the service discovery mechanism to develop a connector in this embodiment, only a template method needs to be developed. The input parameter of the connector is the request message of the client (or the converted first message content mentioned later). The request message includes HTTP Header, Request PATH, Request Parameter, Request Body, etc. The return value is the return message generated by the interface provider end in response to the request message. The developed connector plugin is uploaded and loaded in the form of an independent resource file package Bundle. When loaded, it can be hot-loaded by URLClassLoader (URL class loader) and then instantiated by the service discovery mechanism.

[0070] The development of the connector as a plugin based on the service discovery mechanism in this embodiment can improve the overall flexibility and scalability of the service request processing device that executes the service request processing method. The service discovery mechanism allows the connector to automatically obtain and update relevant information (such as protocol type, address, and port information) in the interface document of the interface provider end at runtime. Even if the service instance of the interface provider end changes (such as addition, deletion, or migration), the connector can automatically adapt without manual configuration modification. The service discovery mechanism is usually combined with load balancing and failover, which can ensure that the connector always connects to healthy and available service instances, improving the overall availability of the system.

[0071] Specifically, in some embodiments of the present invention, the RESTful request service adopted by the client based on the RESTful protocol is based on the HTTP protocol, and information exchange is carried out through request messages in JSON data format. For the Proxy forwarding of requests, common open-source tool components such as Apache HTTP Component and OK-HTTP can be used to initiate and receive requests. For most scenarios, only by configuring information such as the protocol type of the RESTful request, the request method, and common authentication rules, the request forwarding can be completed. For the special interface providers customized by enterprises (such as third-party service platforms), since the authentication rules of such interface providers are often customized based on enterprise requirements, a customized connector plugin for such interface providers is required to perform authentication requests and forward request messages.

[0072] In this regard, the connector plugin types in this embodiment may specifically include a first connector and a second connector. The first connector is a connector set for the customized interface provider, and the second connector is a built-in HTTP general connector. Common basic authentication, API key, Token authentication, Digest authentication, OAuth authentication, etc. configured by most interface providers can be configured in the second configuration item of the HTTP general connector to cover 70% of the business scenarios. For those that cannot implement authentication requests (i.e., authorization) through the HTTP general connector, the first connector is introduced to implement the Proxy forwarding and response of request messages.

[0073] The HTTP general connector in this embodiment can provide powerful service forwarding configuration content, and the content that can be configured includes:

[0074] Request protocol: including HTTP, HTTPS;

[0075] Root path of the request service: configured in an array, multiple can be configured, and load balancing of the interface provider can be achieved in the scenario of configuring multiple;

[0076] CONTEXT of the request service: the fixed service prefix of the interface provider;

[0077] General authentication method of the service: including one of Basic authentication, Token authentication, Digest authentication, etc.;

[0078] Number of abnormal retries of the service: the default is 1 time, and the number of abnormal retries can be customized and configured to 2 times, 3 times, etc., and this embodiment does not make a unique limitation;

[0079] Based on the above content, the configuration items of the HTTP general connector may include the following content:

[0080] {

[0081] "protocol": "http", / / Request protocol type

[0082] "host": ["example1.com", "example2.com"], / / Root path of the requested service

[0083] "contenxt": " / example-content", / / CONTEXT of the requested service

[0084] "authType": "basic", / / Authentication method of the service

[0085] "username": "example-user", / / Username

[0086] "password": "********" / / Password

[0087] }

[0088] Information such as the request protocol type, the root path of the requested service, and the CONTEXT of the requested service are the configuration contents of the first configuration item of the HTTP general connector. Information such as the authentication method of the service (such as Basic authentication), the username, and the password are the configuration contents of the second configuration item. Thus, in this embodiment, 70% of the business scenarios can be authenticated and the request messages can be forwarded through the HTTP general connector.

[0089] For some interface provider ends of enterprise-internal customized third-party service platforms, due to differences in their authentication forms and forwarding methods, the authentication requests and request message forwarding can be implemented through the first connector.

[0090] The first connector developed in this embodiment for authentication forms different from common authentication rules can configure configuration items according to the authentication information configured by the interface provider end. The following are the contents of each configuration item of this first connector:

[0091] {

[0092] "protocol": "https", / / Request protocol type

[0093] "host": ["example1.com", "example2.com"], / / Root path of the requested service

[0094] "contenxt": " / example-content", / / CONTEXT of the requested service

[0095] "token": "example-token", / / Service fixed token

[0096] "secret": "example-secret" / / Secret key

[0097] }

[0098] Information such as the request protocol type, the root path of the requested service, and the CONTEXT of the requested service is the content of the first configuration item of the first connector. Information such as the configured service fixed token and secret key is the content of the second configuration item of the first connector. The corresponding authentication information varies according to the authentication rules and secret keys specified by the specific interface provider. For example, if the service fixed tokens of any two interface providers are the same but the secret keys are different, the content of the secret key part of different first connectors is configured as the secret key content specified by the corresponding interface provider. If the authentication rules of any two interface providers are different, the first connector of the corresponding interface provider modifies the configuration item position where the service fixed token is located to the authentication rule specified by the interface provider.

[0099] Thus, in this embodiment, according to the different interface providers requested by the client, two types of plugins, the first connector and the second connector, can be set to perform plug-in expansion on some authentication information unique to enterprises or other users. The authentication request and the forwarding of the request message are executed through the corresponding connector, realizing flexible management of different interface providers. There is no need for the client to initiate an authentication request to any interface provider, improving the user experience of using the interface provider.

[0100] Generally, the request message of the client is a message in JSON data format. To avoid the situation where some interface providers cannot recognize the request message, the step of sending the request message to the connector according to the corresponding relationship in step S12 of this embodiment includes the following method: determining the syntax format of the programming language supported by the interface provider, converting the request message into the first message content based on the syntax format of the programming language, and sending the first message content to the connector to forward the first message content to the interface provider through the connector. That is to say, in this embodiment, the converted first message content can be sent to the connector to forward the first message content to the interface provider through the connector, avoiding the situation where the interface provider cannot respond due to the request message being transparently transmitted (i.e., transparent transmission, a communication method of transmitting data without modification).

[0101] Please refer to Figure 3, the request message in this embodiment is a message in JSON data format. Before converting the request message into the first message content based on the syntax format of the development language, the method provided in this embodiment further includes the following method steps:

[0102] Step S31: Determine the request characteristics of the request message. The content of the request characteristics includes the first field name and the first field value belonging to the first field name. The types of request characteristics include at least one of request header, request path, request parameters, body field, and cookie field. If the request header (HTTP Header) is accept-ranges: bytes, cache-control: max-age=31536000, its first field names are accept-ranges, cache-control, etc. The first field value of accept-ranges is bytes, and the first field value of cache-control is max-age=31536000. If the cookie field is cookie: token=eyJ0eXAi; userId=123; username=admin, then the first field name of the cookie field is cookie, and the first field value of cookie includes token=eyJ0eXAi, userId=123, username=admin, etc. The first field value of cookie is a key-value pair, and adjacent key-value pairs are separated by the delimiter ";". For example, for the first field value token=eyJ0eXAi, the key is token and the value is eyJ0eXAi. One first field name may have one or more first field values, depending on the type of different request characteristics.

[0103] Step S32: After splitting the content of the request characteristics according to the first splitting rule, obtain the first intermediate message content. The first splitting rule includes the rule of splitting into multiple lines according to different first field names, and / or the rule of splitting multiple different first field values belonging to the same first field name into multiple lines. In this method step, if the request header is accept-ranges: bytes, cache-control: max-age=31536000, after splitting the content of the request header into multiple lines according to different first field names, the following content will be obtained:

[0104] {

[0105] "_HEADER": {

[0106] "accept-ranges": "bytes",

[0107] "cache-control": "max-age=31536000"

[0108] }

[0109] }

[0110] When the cookie field is cookie: token=eyJ0eXAi; userId=123; username=admin, after splitting multiple different first field values belonging to the same first field name in the cookie field into multiple lines, the following content will be obtained:

[0111] {

[0112] "_Cookie": {

[0113] "token": "eyJ0eXAi",

[0114] "userId": "123",

[0115] "username": "admin"

[0116] }

[0117] }

[0118] In the content of the first intermediate state message, the content of each split request feature starts with "{" and ends with "}", and the starting line data of the content is the type name or the first field name of the request feature. The first field name and its first field value are correspondingly set and written into "{}". The first field name and the first field value are separated by a colon ":". If the first field value is a key-value pair, the key and the value in each line are also separated by a colon ":".

[0119] Step S33: Convert the content of the first intermediate state message into the content of the first message based on the syntax format of the development language.

[0120] When the forwarding of the request message can convert the request message of the client into the message format required by the third-party service platform, the specific configurable request features are as follows:

[0121] Request response header, using the variable ${_HEADER.var}.

[0122] Request Cookie, using the variable ${C_Cookie.var}.

[0123] Request path variable, using the variable ${_PATH.var}.

[0124] Request parameter variable (URL parameter in GET value passing), use the variable ${_PARAMETER.var}.

[0125] Request Body variable (Body parameter in POST value passing), use ${$.var}.

[0126] Set the data structure obtained by splitting each request feature according to the first splitting rule as the intermediate body, and each intermediate body is shown in Table 1:

[0127] Table 1

[0128]

[0129] The content of the first intermediate state message obtained by merging the data structures (i.e., intermediate bodies) after splitting different request features is as follows:

[0130] {

[0131] "_HEADER": {

[0132] "accept-ranges": "bytes",

[0133] "cache-control": "max-age=31536000"

[0134] },

[0135] "_Cookie": {

[0136] "token": "eyJ0eXAi",

[0137] "userId": "123",

[0138] "username": "admin"

[0139] },

[0140] "_PATH": {

[0141] "entity": "user",

[0142] "id": "123"

[0143] },

[0144] "_PARAMETER": {

[0145] "a": ["1", "2"],

[0146] "b": "1"

[0147] },

[0148] "username": "admin",

[0149] "address": ["address1", "address2"]

[0150] }

[0151] The content of the first intermediate state message of the above structure is easy to parse and read, which can reduce the pressure during the backend conversion operation process.

[0152] Therefore, the method provided in this embodiment can, before executing step S33, first split the request features according to the first splitting rule to obtain the content of the first intermediate state message. Since each line of data in the content of the first intermediate state message has only one first field name and its first field value, and / or each line is different field values of the same first field name, that is, each first field name and its corresponding first field value are on separate lines, and when a first field name has multiple first field values, each first field value is on a separate line. In this way, the content of the corresponding request features becomes clearer and easier to read, the parsing complexity of the request features by the data parser can be reduced, and parsing errors are easier to locate and correct, with high flexibility, and the data parsing pressure when converting the request message into the content of the first message can be greatly reduced. And if new fields need to be modified or added, the way of displaying line by line will make the modification and addition operations more direct and simple.

[0153] In this embodiment, the development languages supported by the interface providing end include JSON Path, and JSON Path is a language used for querying in JSON data. Then the steps of converting the content of the first intermediate state message into the content of the first message based on the syntax format of the development language include: adjusting the content of the first intermediate state message according to the syntax format of JSON Path to obtain the content of the first message.

[0154] The conversion of the request message uses the complete JSON Path syntax. If it is necessary to use the value of the cache-control parameter in the request header Header as the forwarding input parameter, it can be defined as ${HEADER.cache-control}.

[0155] If it is necessary to use the id parameter in the request path Request Path as the forwarding input parameter, it can be defined as ${_PATH.id}.

[0156] If it is necessary to use the a parameter in the request parameter Request Paramter as the input parameter, it can be defined as ${_PARAMETER.a}.

[0157] If it is necessary to use the first value of parameter a in the request parameter Request Paramter as the input parameter, it can be defined as ${_PARAMETER.a[0]}.

[0158] If it is necessary to use the username parameter in the Body field (request body) as the input parameter, it can be defined as ${$.username} or ${username}.

[0159] In addition to the conversion of the request message, this embodiment may also include the conversion of the request method and content, such as the conversion of methods such as POST, GET, DELETE, etc. If POST is converted to GET, the content of its Request Body needs to be converted to RequestParamter. If GET is converted to POST, the content of Request Paramter needs to be converted to Request Body.

[0160] Thus, after converting the request message into the content of the first intermediate message of an intermediate state structure in this embodiment, the logic of taking values (including expression calculation) from the content of the first intermediate message is used to implement the content format conversion between the request message and the content of the first message, so as to more flexibly adapt to the corresponding interface providing end and avoid the situation of interface providing end response failure.

[0161] Secondly, when the request feature in this embodiment includes the request path, before obtaining the content of the first intermediate message after splitting the content of the request feature according to the first splitting rule, please refer to Figure 4 , the method provided in this embodiment further includes the following method steps:

[0162] Step S41: Parse out the path parameters configured by the client in the request path. The path parameters are the parameters required for the connector to route to the target service interface of the interface providing end.

[0163] Step S42: Configure the path parameters into the first configuration item so that the connector can call the target service interface based on the first configuration item. So that the connector can make an authentication request to the target service interface and send the corresponding message to the target service interface.

[0164] Therefore, when the service interface belonging to a certain interface provider to be accessed by the client changes, the client only needs to dynamically input the path parameter pointing to the target service interface to be accessed in the request path according to the actual needs, and then configure this path parameter in the request path into the first configuration item of the connector. The connector can then accurately call the corresponding target service interface based on the first configuration item. That is to say, the path required for the client to request the target service interface of the interface provider (such as a third-party service platform) will ultimately be the path information formed by the superposition combination of the root path host, the fixed service prefix CONTEXT, and the path parameter configured in the first configuration item of the connector. That is, the forwarded service path supports the variable of the path parameter, and the path parameter can be defined as / forword-url, / forword-url / ${_PATH.user_id}, / forword-url / ${_PARAMETER.name}, / forword-url / ${_BODY.record[0].name}.

[0165] For example, the path of the service interface initially called by the user is / forword-url, but the interface path of the target service interface is / forword-url / A. If the user of the client needs to call the target service interface, the user only needs to place the path parameter A in the request path, and then configure / forword-url / ${_PARAMETER.A} to ensure that the connector forwards the request message to the target service interface. For the user, the call is / forword-url and the path parameter is A. The connector actually calls the target service interface of / forword-url / A in the end, thus improving the operation convenience of the client and further enhancing the user experience of the client and the interface provider.

[0166] In step S13, after the request message is forwarded to the interface provider through the connector, please refer to Figure 5 , the method provided in this embodiment further includes the following steps:

[0167] Step S51: Receive, through the connector, the return message generated by the interface provider in response to the request message;

[0168] Step S52: Determine the return characteristics of the return message, and adjust the return characteristics according to the predetermined return characteristics pre-specified by the client until the content of the return characteristics is consistent with the predetermined return characteristics, and then send the return message to the client. The return characteristics include at least one of the response header, the response body, and the Cookie.

[0169] Thus, before sending the return message to the client, this embodiment can ensure that the content of the return message sent to the client is what the client needs by performing the above step S52. Therefore, when the return content is adjusted at the interface providing end, the client will not be unable to accurately distinguish due to the adjustment of the return content. For example, if the interface providing end normally returns an id, and later the interface providing end adjusts the returned id to id1, then this embodiment can adjust the return feature (id1) according to the predetermined return feature (here it is id) until the content of the return feature is consistent with the predetermined return feature, and finally return id to the client. In this way, the user is directly unaware of whether the interface providing end has adjusted the content of the return message, further improving the user experience.

[0170] The content of the return feature is the message content in JSON data format. The content of the return feature includes a second field name and a second field value belonging to the second field name. The content of the predetermined return feature includes a predetermined field name and a predetermined field value belonging to the predetermined field name. Please refer to Figure 6 , in step S52, the steps of adjusting the content of the return feature according to the predetermined return feature pre-specified by the client until the content of the return feature is consistent with the predetermined return feature include:

[0171] Step S521: After splitting the content of the return feature according to the second splitting rule, obtain the second intermediate state message content. The second splitting rule includes the rule of splitting into multiple lines according to different second field names, and / or the rule of splitting multiple different second field values belonging to the same second field name into multiple lines.

[0172] Step S522: Judge whether the second field value of the second field name with the same name as the predetermined field name is the same as the predetermined field value. If not, adjust the second field value to the predetermined field value. For example, if the predetermined field value is id and the second field value is id1, then adjust the second field value to id, and / or judge whether there is a second field name in the second intermediate state message content that does not exist in the predetermined return feature. If so, delete the second field name and its second field value from the second intermediate state message content. For example, if the name of the second field name in the return feature is a, and the field name a does not exist in the predetermined return feature, then delete the second field name a and its second field value in the return feature from the second intermediate state message content.

[0173] Step S523: After converting the second intermediate state message content into the second message content according to the data exchange format supported by the client, send the second message content to the client as the return message. For example, when the client supports the JSON data format, the second message content obtained by adjusting the adjusted second intermediate state message content to the JSON data format can be returned to the client.

[0174] In step S523, when converting the content of the second intermediate state message into the content of the second message according to the data exchange format supported by the client, the following methods may be specifically included:

[0175] The request message conversion configuration is a conversion from the client message to the interface provider message, while the response message conversion is a conversion from the return message of the interface provider response to the client message. Its configured conversion logic is the same as that of the request message conversion logic, and the configurable content is reduced. The final return is transmitted in the form of Body, response header, and Cookie. The specific configurable content includes:

[0176] Return the response header, using the variable ${_HEADER.var}.

[0177] Return the Cookie, using the variable ${C_Cookie.var}.

[0178] Return the Body variable (the Body message returned by the interface provider request), using ${$.var}.

[0179] In the conversion process, first convert it into the content of the second intermediate state message according to the second splitting rule, then convert the content of the second intermediate state message into the content of the second message according to the data exchange format supported by the client, and finally respond the content of the second message to the client in the form of a response message.

[0180] Set the data structure after splitting each return feature according to the second splitting rule as the intermediate body. Each intermediate body is shown in Table 2:

[0181] Table 2

[0182]

[0183] After merging the intermediate bodies of each return feature in Table 2, the content of the second intermediate state message obtained is as follows:

[0184] {

[0185] "_HEADER": {

[0186] "content-type": "application / json",

[0187] "cache-control": "no-cache, no-store, max-age=0, must-revalidate"

[0188] },

[0189] "_Cookie": {

[0190] "token": "eyJ0eXAi",

[0191] "userId": "123",

[0192] "username": "admin"

[0193] },

[0194] "system":"EDIWEB"

[0195] ,"queryType":"Collection card information"

[0196] ,"queryName":"Collection card information query"

[0197] ,"url":" / onesite / truckInfo / list"

[0198] ,"userToken":"AAA"

[0199] }

[0200] Therefore, through the above-mentioned steps S521 to S523, not only the adaptive adjustment and configuration of the return message is achieved, but also because before adjusting the content of the return message, the return characteristics of the return message are first split into the form of the second intermediate state message content according to the second splitting rule, and because each line of data in the second intermediate state message content has only one second field name and its second field value, and / or each line has different second field values ​​for the same second field name, that is, each second field name and its corresponding second field value are in a separate line and when a second field name has multiple second field values, each second field value is in a separate line, therefore, the content of the corresponding return characteristics becomes clearer and easier to read, which can reduce the difficulty of adjusting and deleting the relevant second field values ​​and second field names, thereby greatly reducing the conversion pressure when converting the return message into the second message content.

[0201] As described above, when the embodiment of the present invention builds an API interface service market based on the enterprise itself, it provides a product design idea and a technical implementation solution for the scenario where the three-party RESTful API interfaces cannot be managed in a flexible configuration manner. Based on the authentication requirements of the three-party RESTful service itself, a general HTTP connector or a customized first connector is used to implement the request authentication during the forwarding of the three-party service. Based on the message content in the intermediate state (i.e., the first intermediate state message content and the second intermediate state message content) and the JSON PATH technology, the flexible conversion of the request message and the response message is realized, and the conversion content supported includes message contents such as HTTP Header, Cookie, PATH (path), Request Parameter, Request Body, and Response Body.

[0202] The second embodiment of the present invention also provides a service request processing device. Please refer to Figure 7 , the device includes a service connection module and a service gateway. The service connection module is used to create a corresponding relationship between a pre-configured connector and the interface provider. The connector is used to initiate an authentication request to the interface provider and forward the request message generated when the client initiates a RESTful request to the interface provider to the interface provider. The service gateway is used to receive the request message and send the request message to the connector through the service connection module according to the corresponding relationship. The service connection module is also used to initiate an authentication request to the interface provider through the connector, and after the authentication request passes, forward the request message to the interface provider through the connector.

[0203] Therefore, for the service request processing device provided in this embodiment, after creating the corresponding relationship between the connector and the interface provider, the received request message can be sent to the connector according to the corresponding relationship, so as to initiate an authentication request to the interface provider through the connector, and after the authentication request passes, forward the request message to the interface provider through the connector. That is to say, in this embodiment, the client does not need to send an authentication request related to service authentication to the three-party service platform serving as the interface provider, but after initiating a RESTful request, an authentication request is initiated to the interface provider through the connector. After the interface provider to which the client initiates the RESTful request changes, the corresponding connector corresponding to the interface provider can also be flexibly found according to the created corresponding relationship, so as to use the corresponding connector to replace the client to implement the corresponding authentication request and the forwarding of the request message, and the authentication method and requirements of any three-party service platform can be realized through the configured connector, realizing the flexible management of different three-party service platforms and improving the user experience of the client and the interface provider.

[0204] The connector configured in the service request processing device unifies the configuration of a certain type of interface provider. Multiple forwarding requests can be configured for one type of interface provider, and a single forwarding request needs to be configured separately. The configurable content of the forwarding request includes:

[0205] Request path: The path for the client to request the service gateway is globally unified and serves as the request entry for the client. The request path supports variables, and the variables can be defined as / exmaple-url, / example-url / {user_id}.

[0206] Request method: The methods for the client to request the service gateway include GET (GET is used to obtain information about a specified resource from the interface provider), POST (POST is used to submit data to be processed to the interface provider), DELETE (DELETE is used to delete a specified resource on the interface provider), etc., for the forwarded service path.

[0207] The path for requesting a third-party service will ultimately be the overlay of the host and context configured in the connector and this configured path to form the final path. For example, the path of the service interface initially called by the user is / forword-url, but the interface path of the target service interface is / forword-url / A. If the user of the client needs to call the target service interface, the user only needs to place the path parameter A in the request path and then configure / forword-url / ${_PARAMETER.A} to ensure that the connector forwards the request message to the target service interface. For the user, the call is made to / forword-url with the path parameter A, and the connector actually calls the target service interface of / forword-url / A in the end, thus improving the operation convenience of the client and further enhancing the user experience of the client and the interface provider. The forwarded service path supports the variable of path parameters, and the variables can be defined as / forword-url, / forword-url / ${_PATH.user_id}, / forword-url / ${_PARAMETER.name}, / forword-url / ${_BODY.record[0].name}.

[0208] The request methods that the service gateway finally forwards to the interface provider through the connector include GET, POST, DELETE, etc.

[0209] Request timeout: The timeout response time for the client to request the service gateway.

[0210] Request third-party timeout: The timeout for the forwarding request of the third-party service.

[0211] The number of retry requests for the third party, which is the number of retries when the third-party service is abnormal.

[0212] The configuration for forwarding requests defines some configuration information for the client to request the service gateway and the service gateway to forward the third-party service through the connector, thus providing fixed rules for the Proxy forwarding of the service and ensuring the orderly and stable operation of the overall device.

[0213] Among them, before the service connection module creates the corresponding relationship between the pre-configured connector and the interface provider, the service connection module performs the following steps: Obtain the interface document of the interface provider to configure the connector according to the interface document, and the interface document includes interaction information and authentication information. Among them, the interaction information is used to describe the information required for the client to interact with the interface provider, so that the configured connector can send the request message to the interface provider based on the interaction information, and the authentication information includes the authentication rules for the interface provider to authenticate the service request initiated by the client and the secret key required for authentication based on the authentication rules, so that the connector can initiate an authentication request to the interface provider based on the authentication information. For the specific interaction information and authentication information, please refer to the content provided in the first embodiment of the present invention, and this embodiment will not be elaborated here.

[0214] Thus, through the connector obtained by the service connection module according to the configuration of the interface document in this embodiment, no matter what authentication rules are adopted by the interface provider, when the client initiates a restful request to the corresponding interface provider, the configured connector corresponding to the requested interface provider can initiate an authentication request to the interface provider based on the authentication information. This authentication request process does not require the execution and participation of the client, can flexibly manage interface providers with different authentication rules, and improves the user's operation convenience and the usage experience of the interface provider.

[0215] Such as Figure 7As shown in the figure, the service connection module is configured with a general HTTP service connector, a first connector L1, a first connector L2, etc. Among them, in the created corresponding relationship, if the interface providing end corresponding to the general HTTP service connector is J1, the interface providing end corresponding to the first connector L1 is J2, and the interface providing end corresponding to the first connector L2 is J3. If the client initiates a restful request to the interface providing end J1, the service connection module calls the general HTTP service connector to initiate an authentication request to the interface providing end J1 according to the corresponding relationship, and then sends the request message to the interface providing end J1. If the client initiates a restful request to the interface providing end J2, the service connection module calls the first connector L1 to initiate an authentication request to the interface providing end J2 according to the corresponding relationship, and then sends the request message to the interface providing end J2. Thus, no matter which interface providing end the client initiates a restful request to, the service connection module can call the corresponding connector to perform authentication requests and forward the message, without the client having to perform cumbersome authentication operations, greatly improving the user experience.

[0216] Among them, when the service connection module executes the step of obtaining the interface document of the interface providing end to configure the connector according to the interface document, the following method steps can be specifically executed:

[0217] Step S21: Determine the configuration items required to form the connector. The configuration items include a first configuration item and a second configuration item. The first configuration item is used to describe the interaction information, and the second configuration item is used to describe the authentication information.

[0218] Step S22: Parse out the interaction information and authentication information in the interface document, and inject the interaction information into the first configuration item and the authentication information into the second configuration item to obtain the resource file package required to form the connector.

[0219] Step S23: Load the resource file package to obtain the connector and instantiate the connector. The main purpose of instantiating the connector is to convert the loaded connector class into a specific object. When a client subsequently initiates a restful request to the interface providing end corresponding to this connector, the corresponding connector object can be operated and used at any time.

[0220] Thus, the service connection module in this embodiment can, after determining the configuration items required for the connector, inject the parsed interaction information and authentication information in the interface document into the corresponding configuration items to obtain the original resource file package of the connector. Subsequently, only by loading this resource file package and instantiating it can it provide authentication request and request message forwarding services for the client.

[0221] When injecting the interaction information and authentication information in the interface document into the corresponding configuration items in this embodiment, the request protocol type, root path, etc. of the interaction information need to be injected into the first configuration item, so that the connector can forward the request message to the interface provider end according to the information in the first configuration item, and the authentication rule and key of the authentication information are injected into the second configuration item, so that the connector can perform the operation of the authentication request according to the information in the second configuration item. By directly injecting the corresponding information into the corresponding configuration items in this way, the service connection module can ensure that the connector dynamically obtains and uses the corresponding information during operation, without hard-coding the interaction information and authentication information, improving the flexibility of the connector to adapt to different environments and requirements. Secondly, it is also convenient for the modification and maintenance of the corresponding information. When the information such as the address and port of the target interface provider end changes, only the information of the corresponding configuration item in the resource file package needs to be modified, without modifying the code.

[0222] The steps for the service connection module to load the resource file package to obtain the connector include: using a class loader to perform hot loading on the resource file package. Thus, the service connection module performs hot loading on the resource file package. Subsequently, as long as the resource file package of the configured corresponding interface provider end is obtained, the corresponding connector can be obtained and used in real time, and then operations such as performing the corresponding authentication request and forwarding the message can be performed through the connector, and the service request processing device can obtain the corresponding connector in real time without restarting the service.

[0223] The steps for the service connection module to obtain the interface document of the interface provider end to configure the connector may specifically include: using a service discovery mechanism to obtain the interface document and configuring the connector according to the interface document through the service discovery mechanism. The service discovery mechanism (fully named Service Provider Interface, abbreviated as SPI) allows the application to dynamically load and discover providers (such as the interface provider end that provides the interface document in this embodiment) during operation and interact with them, realizing the decoupling of the application and the service provider. SPI is very suitable for the development of connectors as a plug-in, improving the dynamic configuration and usage efficiency of the connector. Specifically, when the service connection module uses the service discovery mechanism for the development of the connector, only a template method needs to be developed. The input parameter of the connector is the request message of the client (or the converted first message content mentioned later). The request message includes HTTP Header, Request PATH, Request Parameter, Request Body, etc., and the return value is the return message generated by the interface provider end in response to the request message. The plug-in for developing the connector is uploaded and loaded in the form of an independent resource file package Bundle. During loading, it can be hot-loaded by the URLClassLoader (URL class loader) and then instantiated by the service discovery mechanism.

[0224] The service connection module develops the connector, a type of plug-in, based on the service discovery mechanism, which can improve the overall flexibility and scalability of the service request processing device. The service discovery mechanism allows the connector to automatically obtain and update relevant information (such as protocol type, address, and port information) in the interface document of the interface provider at runtime. Even if the service instance of the interface provider changes (such as addition, deletion, or migration), the connector can automatically adapt without manual configuration modification. The service discovery mechanism is usually combined with load balancing and failover to ensure that the connector always connects to healthy and available service instances, improving the overall availability of the system.

[0225] The types of connector plug-ins configured by the service connection module may specifically include a first connector and a second connector. For the specific configuration methods and content of these two connectors, please refer to the content provided in the first embodiment of the present invention, which will not be elaborated here. Based on the different interface providers requested by the client, the service connection module uses two plug-ins, the first connector and the second connector, to perform plug-in extension on some authentication information unique to enterprises or other users. The corresponding connector is used to execute the authentication request and forward the request message, realizing flexible management of different interface providers without the client initiating an authentication request to any interface provider, improving the user experience of using the interface provider.

[0226] Generally, the request message of the client is in the JSON data format. To avoid the situation where some interface providers cannot recognize the request message, the device in this embodiment further includes a first message converter. Before the service connection module of this embodiment sends the request message to the connector according to the corresponding relationship, the service gateway can determine the syntax format of the development language supported by the interface provider through the first message converter, so that the first message converter converts the request message into the first message content based on the syntax format of the development language and sends the first message content to the connector of the service connection module, and the first message content is forwarded to the interface provider through the connector. That is to say, in this embodiment, the converted first message content can be sent to the connector through the first message converter, and the first message content is forwarded to the interface provider through the connector, avoiding the situation where the interface provider cannot respond due to the pass-through of the request message.

[0227] The request message in this embodiment is a message in JSON data format. Before the service gateway converts the request message into the first message content based on the syntax format of the development language through the first message converter, the service gateway also determines the request characteristics of the request message. The content of the request characteristics includes the first field name and the first field value belonging to the first field name. The types of request characteristics include at least one of request headers, request paths, request parameters, body fields, and cookie fields. The service gateway splits the content of the request characteristics according to the first splitting rule to obtain the first intermediate message content. The first splitting rule includes a rule of splitting into multiple lines according to different first field names, and / or a rule of splitting multiple different first field values belonging to the same first field name into multiple lines. The service gateway converts the first intermediate message content into the first message content based on the syntax format of the development language through the first message converter.

[0228] Thus, before the first message converter in this embodiment executes step S33, the service gateway first splits the request characteristics according to the first splitting rule to obtain the first intermediate message content. Since each line of data in the first intermediate message content has only one first field name and its first field value, and / or each line is a different field value of the same first field name, that is, each first field name and its corresponding first field value are on separate lines and each first field value is on a separate line when there are multiple first field values for a first field name. In this way, the content of the corresponding request characteristics becomes clearer and more readable, which can reduce the parsing complexity of the first message converter for the request characteristics, and make parsing errors easier to locate and correct. It has high flexibility and can greatly reduce the data parsing pressure when the first message converter converts the request message into the first message content. And if new fields need to be modified or added, the line-by-line display method will make the modification and addition operations more direct and simple.

[0229] In this embodiment, the development languages supported by the interface provider include JSON Path, which is a language used for querying in JSON data. Then the step of the first message converter converting the first intermediate message content into the first message content based on the syntax format of the development language includes: adjusting the first intermediate message content according to the syntax format of JSON Path to obtain the first message content.

[0230] The conversion of the request message uses the complete JSON Path syntax. If it is necessary to use the value of the cache-control parameter in the request header Header as the forwarding input parameter, it can be defined as ${HEADER.cache-control}.

[0231] If it is necessary to use the id parameter in the request path Request Path as the forwarding input parameter, it can be defined as ${_PATH.id}.

[0232] If it is necessary to use the a parameter in the request parameter Request Paramter as the input parameter, it can be defined as ${_PARAMETER.a}.

[0233] If it is necessary to use the first value of the a parameter in the request parameter Request Paramter as the input parameter, it can be defined as ${_PARAMETER.a[0]}.

[0234] If it is necessary to use the username parameter in the Body field (request body) as the input parameter, it can be defined as ${$.username} or ${username}.

[0235] In addition to the conversion of the request message, this embodiment may also include the conversion of the request method and content, such as the conversion of methods such as POST, GET, DELETE, etc. If POST is converted to GET, the content of the Request Body needs to be converted to RequestParamter. If GET is converted to POST, the content of Request Paramter needs to be converted to the Request Body.

[0236] Thus, after the service gateway converts the request message into the content of the first intermediate message of an intermediate state structure, the logic of taking values (including expression calculation) from the content of the first intermediate message is used to implement the content format conversion between the request message and the content of the first message, so as to more flexibly adapt to the corresponding interface providing end and avoid the situation of the interface providing end responding with failure.

[0237] Secondly, when the request feature in this embodiment includes the request path, before the service gateway splits the content of the request feature according to the first splitting rule to obtain the content of the first intermediate message, the service gateway parses out the path parameters configured by the client in the request path and sends the path parameters to the service connection module. The path parameters are the parameters required for the connector to route to the target service interface of the interface providing end. The service connection module configures the path parameters into the first configuration item so that the connector can call the target service interface based on the first configuration item.

[0238] Thus, when the service interface belonging to a certain interface provider to be accessed by the client changes, the client only needs to dynamically input the path parameter pointing to the target service interface to be accessed in the request path according to actual needs, and then the service connection module configures this path parameter in the request path into the first configuration item of the connector, and the connector can accurately call the corresponding target service interface based on the first configuration item. That is to say, the path required for the client to request the target service interface of the interface provider (such as a third-party service platform) will ultimately be the path information formed by the superposition combination of the root path host, the fixed service prefix CONTEXT, and the path parameter configured in the first configuration item of the connector.

[0239] After the service connection module forwards the request message to the interface provider through the connector, the service connection module also receives the return message generated by the interface provider in response to the request message through the connector, and determines the return characteristics of the return message through the connector. After the connector adjusts the return characteristics according to the predetermined return characteristics specified in advance by the client until the content of the return characteristics is consistent with the predetermined return characteristics, the service connection module sends the return message to the client through the service gateway. The return characteristics include at least one of the response header, the response body, and the Cookie.

[0240] Thus, before the service connection module sends the return message to the client, the above steps can be executed through the connector to ensure that the content of the return message sent by the service gateway to the client is what the client needs. Therefore, when the interface provider adjusts the return content, the client will not be unable to accurately distinguish due to the adjustment of the return content. For example, if the interface provider normally returns id, and later the interface provider adjusts the returned id to id1, the service connection module can adjust the return characteristic (id1) according to the predetermined return characteristic (here it is id) until the content of the return characteristic is consistent with the predetermined return characteristic, and finally return id to the client. In this way, the user is directly unaware of whether the interface provider has adjusted the return message content, further improving the user experience.

[0241] The content of the returned feature is a message content in JSON data format. The content of the returned feature includes a second field name and a second field value belonging to the second field name. The content of the predetermined returned feature includes a predetermined field name and a predetermined field value belonging to the predetermined field name. The device in this embodiment further includes a second message converter. The steps for the connector to adjust the content of the returned feature according to the predetermined returned feature pre-specified by the client until the content of the returned feature is consistent with the predetermined returned feature include: splitting the content of the returned feature according to the second splitting rule to obtain the second intermediate message content. The second splitting rule includes a rule of splitting into multiple lines according to different second field names, and / or a rule of splitting multiple different second field values belonging to the same second field name into multiple lines. Determine whether the second field value of the second field name with the same name as the predetermined field name is the same as the predetermined field value. If not, adjust the second field value to the predetermined field value. For example, if the predetermined field value is id and the second field value is id1, then adjust the second field value to id, and / or determine whether there is a second field name in the second intermediate message content that does not exist in the predetermined returned feature. If so, delete the second field name and its second field value from the second intermediate message content. After the connector converts the second intermediate message content into the second message content in the data exchange format supported by the client through the second message converter, the second message content is sent to the client as a returned message through the service gateway. When the client supports the JSON data format, the second message content obtained by adjusting the adjusted second intermediate message content to the JSON data format can be returned to the client.

[0242] When the second message converter converts the second intermediate message content into the second message content in the data exchange format supported by the client, the following method steps can be specifically executed: The request message conversion configures a conversion from the client message to the interface provider message, and the response message conversion configures a conversion from the returned message of the interface provider response to the client message. Its configured conversion logic is consistent with the conversion logic of the request message, and the configurable content is reduced. The final return is transmitted in the form of Body, response header, and Cookie. The specific configurable content includes:

[0243] Return the response header, using the variable ${_HEADER.var}.

[0244] Return the Cookie, using the variable ${C_Cookie.var}.

[0245] Return the Body variable (the Body message returned by the interface provider request), using ${$.var}.

[0246] The conversion process first converts to the second intermediate state message content according to the second splitting rule, then converts the second intermediate state message content into the second message content according to the data exchange format supported by the client, and finally responds the second message content to the client in the form of a response message.

[0247] Set the data structure obtained by splitting each return feature according to the second splitting rule as the intermediate body, and each intermediate body is shown in Table 2 of the first embodiment. After merging the intermediate bodies of each return feature in Table 2, the second intermediate state message content is obtained.

[0248] Thus, the device provided in this embodiment not only realizes the adaptive adjustment and configuration of the return message. Since before adjusting the content of the return message, the return features of the return message are first split into the form of the second intermediate state message content according to the second splitting rule through the connector, and since each line of data in the second intermediate state message content has only one second field name and its second field value, and / or, each line is a different second field value of the same second field name, that is, each second field name and its corresponding second field value are on a separate line and when there are multiple second field values for one second field name, each second field value is on a separate line, the content of the corresponding return feature becomes clearer and easier to read, which can reduce the difficulty of adjusting and deleting operations on the relevant second field values and second field names, and thus greatly reduce the conversion pressure when the second message converter converts the return message into the second message content.

[0249] As can be seen from the above, the embodiments of the present invention provide a product design idea and a technical implementation solution for the scenario where it is impossible to manage the third-party RESTful API interfaces in a flexible configuration manner when building an API interface service market based on the enterprise's own construction. Based on the authentication requirements of the third-party restful service itself, a general HTTP connector or a customized first connector is used to implement the request authentication during the forwarding of the third-party service. Based on the intermediate state message content (i.e., the first intermediate state message content and the second intermediate state message content) and JSON PATH technology, flexible conversion of the request message and the return message is realized, and the supported conversion content includes message contents such as HTTP Header, Cookie, PATH (path), Request Parameter, Request Body, Response Body, etc.

[0250] When the interface providing end is a third-party service platform, after the service request processing device provided in this embodiment is configured, it can perform online forwarding tests on the authentication requests and messages (request messages and return messages) sent by the client to the third-party service platform through the connector, and publish them to the production state after the test is completed.

[0251] After the configuration of a single forwarding service is completed, the service request processing device can provide an online debugging function. The service request processing device inputs service call parameters in the form of a visual pop-up box, obtains the full message content through the test service gateway, and then converts it into the message content required by the third-party service platform. It is forwarded to the third-party service platform through the connector, and then the response message is converted into the format required by the client through the second message converter and responded to the debugging interface. The entire process completes the management ability of the third-party service platform in a configuration-based manner. After testing without problems, the release button can be clicked to release it to the production environment for client calls. The authentication requests, traffic limiting, and circuit breaking of client calls can all be uniformly managed by the service request processing device.

[0252] The key point of the embodiment of the present invention lies in a flexible service authentication plugin system. Through the built-in HTTP general connector and the custom plugin connector that can be dynamically uploaded and loaded, flexible authentication adaptation at the interface providing end is realized. At the same time, based on the characteristics of the restful protocol and the HTTP protocol, through the general configuration method using JSON PATH expressions and JSON data formats, the content conversion of the request message and the return message can be easily realized without special technical thresholds.

[0253] The connectors configured by using the plug-in mechanism in this embodiment (such as the custom-developed first connector and the built-in HTTP general connector) realize the management of any authentication method at the interface providing end and message forwarding. This management method has high efficiency and low configuration difficulty.

[0254] Based on the concept of connector plug-in, there is no need to customize the application to shield the authentication information required for authentication at the interface providing end (such as the third-party service platform), nor is it necessary to assemble the authentication information at the interface providing end by means of hard coding, scripting languages, etc. An implementation method is realized in which a class of interface providing ends are configured or customized once, and multiple service forwards are configured multiple times.

[0255] For messages based on the Header, Cookie, Request Paramter of the HTTP protocol and the RequestBody, Reponse Body of the restful protocol, only the widely used JSON PATH expressions are used, and the flexible conversion and adaptation of the message content can be realized without introducing scripting languages, custom DSLs, etc. A cookie is a small data fragment used to track and save user information.

[0256] In some embodiments of the present invention, the service gateway can be made to only forward services, and the authentication information is resolved by the microservice application itself. For example, based on the service gateway configuration, the routing forwarding policy for third-party requests is configured, and each third-party service platform customizes a microservice application to implement the decoding of authentication information and the forwarding of protocol content, that is, each platform customizes a microservice implementation. Flexible assembly of authentication information can also be achieved through the built-in scripting language. For example, when configuring the forwarding service, the embedded Python scripting language is used to assemble the authentication-related authentication information into the message header, message body, etc., to achieve the configuration-based forwarding of third-party services. For the forwarding of request and response messages, a certain degree of content conversion can be achieved through the configuration of field mapping, but the overall degree of configuration is not high. For the message conversion of flexible content, a third-party DSL language or scripting language is introduced, and the request information and message content are passed to the execution environment through the context, and then returned after processing.

[0257] The above are only the preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, various changes and modifications can be made to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included within the protection scope of the present application.

Claims

1. A service request processing method, characterized in that: include: Create a correspondence between a pre-configured connector and an interface provider, wherein the connector is used to initiate an authentication request to the interface provider and forward a request message generated when a client initiates a restful request to the interface provider to the interface provider; receiving the request message, and sending the request message to the connector according to the corresponding relationship; Initiating the authentication request to the interface provider through the connector, and forwarding the request message to the interface provider through the connector after the authentication request is passed; Before creating a correspondence between a pre-configured connector and an interface provider, the method includes: Acquire an interface document of the interface provider to configure the connector according to the interface document, wherein the interface document includes interaction information and authentication information; The interaction information is information used to describe the interaction between the client and the interface provider, so that the connector sends the request message to the interface provider based on the interaction information, and, The authentication information includes an authentication rule for the interface provider to authenticate the service request initiated by the client and a key required for authentication based on the authentication rule, so that the connector initiates the authentication request to the interface provider based on the authentication information; The step of obtaining the interface document of the interface provider to configure the connector according to the interface document includes: Determine configuration items required to form the connector, the configuration items include a first configuration item and a second configuration item, the first configuration item is used to describe the interaction information, and the second configuration item is used to describe the authentication information; Parsing the interaction information and the authentication information in the interface document, injecting the interaction information into the first configuration item and injecting the authentication information into the second configuration item, so as to obtain a resource file package required to constitute the connector; Load the resource file package to obtain the connector and instantiate the connector; The step of sending the request message to the connector according to the corresponding relationship includes: Determine the syntax format of the development language supported by the interface provider, convert the request message into a first message content based on the syntax format of the development language, and send the first message content to the connector, so as to forward the first message content to the interface provider through the connector; The request message is a message in JSON data format, and before converting the request message into the first message content based on the grammatical format of the development language, the method further includes: Determine a request feature of the request message, wherein the content of the request feature includes a first field name and a first field value belonging to the first field name, and the type of the request feature includes at least one of a request header, a request path, a request parameter, a body field, and a cookie field; Splitting the content of the request feature according to a first splitting rule to obtain first intermediate message content, wherein the first splitting rule includes a rule for splitting into multiple lines according to different first field names and / or a rule for splitting multiple different first field values ​​belonging to the same first field name into multiple lines; Converting the first intermediate message content into the first message content based on the grammatical format of the development language; When the request feature includes the request path, before splitting the content of the request feature according to the first splitting rule to obtain the first intermediate state message content, the method further includes: Parsing out the path parameters configured by the client in the request path, where the path parameters are the parameters required for the connector to route to the target service interface of the interface provider; configuring the path parameter into the first configuration item, so that the connector calls the target service interface based on the first configuration item and forwards the request message to the target service interface; After forwarding the request message to the interface provider through the connector, the method further includes: receiving, through the connector, a return message generated by the interface provider in response to the request message; Determine the return characteristics of the return message, and adjust the return characteristics according to the predetermined return characteristics pre-defined by the client until the content of the return characteristics is consistent with the predetermined return characteristics, and then send the return message to the client, wherein the return characteristics include at least one of a response header, a response body, and a cookie.

2. The service request processing method according to claim 1, characterized in that: The step of loading the resource file package to obtain the connector includes: A class loader is used to hot load the resource file package.

3. The service request processing method according to claim 1, characterized in that: The step of obtaining the interface document of the interface provider to configure the connector according to the interface document includes: The interface document is acquired by using a service discovery mechanism, and the connector is configured according to the interface document through the service discovery mechanism.

4. The service request processing method according to claim 1, characterized in that: The development language includes a JSON path, which is a language used to query in JSON data. The step of converting the first intermediate state message content into the first message content based on the grammatical format of the development language includes: The first intermediate state message content is adjusted according to the grammatical format of the JSON path to obtain the first message content.

5. The service request processing method according to claim 1, characterized in that: The content of the return feature is a message content in JSON data format, the content of the return feature includes a second field name and a second field value belonging to the second field name, the content of the predetermined return feature includes a predetermined field name and a predetermined field value belonging to the predetermined field name, and the step of adjusting the content of the return feature according to the predetermined return feature predefined by the client until the content of the return feature is consistent with the predetermined return feature includes: Splitting the content of the returned feature according to a second splitting rule to obtain second intermediate message content, wherein the second splitting rule includes a rule for splitting into multiple lines according to different second field names and / or a rule for splitting multiple different second field values ​​belonging to the same second field name into multiple lines; Determine whether the second field value of the second field name that is the same as the predetermined field name is the same as the predetermined field value, and if not, adjust the second field value to the predetermined field value, and / or determine whether the second intermediate state message content has the second field name that does not exist in the predetermined return feature, and if so, delete the second field name and its second field value from the second intermediate state message content; After converting the second intermediate state message content into the second message content according to the data exchange format supported by the client, the second message content is sent to the client as the return message.

6. A service request processing device, characterized in that: include: A service connection module, the service connection module is used to create a correspondence between a pre-configured connector and an interface provider, the connector is used to initiate an authentication request to the interface provider and forward a request message generated when a client initiates a restful request to the interface provider to the interface provider; A service gateway, the service gateway is used to receive the request message, and send the request message to the connector through the service connection module according to the corresponding relationship; The service connection module is further used to initiate the authentication request to the interface provider through the connector, and forward the request message to the interface provider through the connector after the authentication request is passed; Before the service connection module creates a correspondence between a pre-configured connector and an interface provider, the service connection module performs the following steps: obtaining an interface document of the interface provider to configure the connector according to the interface document, wherein the interface document includes interaction information and authentication information; wherein the interaction information is information used to describe the information required for the client to interact with the interface provider, so that the connector can send the request message to the interface provider based on the interaction information, and the authentication information includes an authentication rule for the interface provider to authenticate the service request initiated by the client and a key required for authentication based on the authentication rule, so that the connector initiates the authentication request to the interface provider based on the authentication information; When the service connection module executes the step of obtaining the interface document of the interface provider to configure the connector according to the interface document, the following method steps may be specifically executed: Determine configuration items required to form the connector, the configuration items include a first configuration item and a second configuration item, the first configuration item is used to describe the interaction information, and the second configuration item is used to describe the authentication information; Parsing the interaction information and the authentication information in the interface document, injecting the interaction information into the first configuration item and injecting the authentication information into the second configuration item, so as to obtain a resource file package required to constitute the connector; Load the resource file package to obtain the connector and instantiate the connector; Before the service connection module sends the request message to the connector according to the corresponding relationship, the service gateway determines the syntax format of the development language supported by the interface provider through the first message converter, so that the first message converter converts the request message into the first message content based on the syntax format of the development language, and sends the first message content to the connector of the service connection module, so as to forward the first message content to the interface provider through the connector; The request message is a message in JSON data format. Before the service gateway converts the request message into the first message content through the first message converter based on the syntax format of the development language, the service gateway also determines the request characteristics of the request message, the content of the request characteristics includes a first field name and a first field value belonging to the first field name, and the type of the request characteristics includes at least one of a request header, a request path, a request parameter, a body field, and a cookie field; the service gateway obtains the first intermediate message content after splitting the content of the request characteristics according to the first splitting rule, and the first splitting rule includes a rule of splitting into multiple lines according to different first field names, and / or a rule of splitting multiple different first field values ​​belonging to the same first field name into multiple lines; the service gateway converts the first intermediate message content into the first message content through the first message converter based on the syntax format of the development language; When the request feature includes a request path, the service gateway parses the path parameters configured by the client in the request path and sends the path parameters to the service connection module before splitting the content of the request feature according to the first splitting rule to obtain the first intermediate message content. The path parameters are the parameters required for the connector to route to the target service interface of the interface provider; the service connection module configures the path parameters into the first configuration item so that the connector calls the target service interface based on the first configuration item and forwards the request message to the target service interface; After the service connection module forwards the request message to the interface provider through the connector, the service connection module also receives the return message generated by the interface provider in response to the request message through the connector, and determines the return characteristics of the return message through the connector. The connector adjusts the return characteristics according to the predetermined return characteristics pre-defined by the client until the content of the return characteristics is consistent with the predetermined return characteristics. The service connection module sends the return message to the client through the service gateway. The return characteristics include at least one of a response header, a response body, and a cookie.

Images