Service request processing method and device

Abstract

The invention discloses a service request processing method and device, and relates to the technical field of networks. The service request processing method comprises the following steps: creating a pre-configured corresponding relationship between a connector and an interface providing end, wherein the connector is used for initiating an authentication request to the interface providing end and forwarding a request message generated when a client initiates a restful request to the interface providing end to the interface providing end; receiving a request message, and sending the request message to the connector according to the corresponding relationship; initiating an authentication request to the interface providing end through the connector, and forwarding a request message to the interface providing end through the connector after the authentication request passes; according to the invention, the problem that a user needs to execute different authentication modes for different three-party service platforms is solved.

Description

Technical Field

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

[0002] REST (representational state transfer) is a software architecture style that provides a set of design principles and constraints. RESTful refers to applications or designs that meet these constraints and principles. The application programming interface (API) encapsulated using the REST principles is called a RESTful API interface. The client can send a RESTful request to the RESTful API interface to get the interface request. Since the RESTful API is simple and easy to use, it is widely used in many network software. The RESTful interface runs on the network, and the authentication problem of its security authentication has always received widespread attention.

[0003] At present, when calling the services of third-party service platforms, the service authentication method is usually limited to the RESTful API interface of a specific third-party service platform. However, for some third-party service platforms customized within enterprises, due to the differences in the authentication forms of the RESTful API interfaces of different third-party service platforms, users are required to perform different authentication methods for different third-party service platforms, which is cumbersome and difficult to achieve flexible management of different third-party service platforms, reducing the user experience of the RESTful API interface. Summary of the invention

[0004] The main purpose of the present invention is to provide a service request processing method and device to solve the problem in the background technology that different third-party service platforms require users to perform different authentication methods.

[0005] According to one aspect of the present application, a service request processing method is provided, comprising: 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; The authentication request is initiated to the interface provider through the connector, and after the authentication request is passed, the request message is forwarded to the interface provider through the connector.

[0006] Furthermore, before creating the correspondence between the pre-configured connector and the 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 the authentication rules used by the interface provider to authenticate the service request initiated by the client and the key required for authentication based on the authentication rules, so that the connector initiates the authentication request to the interface provider based on the authentication information.

[0007] Furthermore, 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; The resource file package is loaded to obtain the connector and instantiate the connector.

[0008] Furthermore, 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.

[0009] Furthermore, 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.

[0010] Further, 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.

[0011] Furthermore, 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; The first intermediate message content is converted into the first message content based on the grammatical format of the development language.

[0012] Furthermore, 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 syntax format of the JSON path to obtain the first message content.

[0013] Further, when the request feature includes the request path, before obtaining the first intermediate message content after splitting the content of the request feature according to the first splitting rule, 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; The path parameter is configured 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.

[0014] Furthermore, 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.

[0015] Further, the content of the return feature is a message content in a 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 pre-specified 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.

[0016] On the other hand, the present application also provides a service request processing device, characterized in that it includes: 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 configured 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.

[0017] The service request processing method provided by the present invention can send the received request message to the connector according to the corresponding relationship after the corresponding relationship between the connector and the interface provider is created, thereby initiating an 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. In other words, the client in the present invention does not need to make an authentication request related to service authentication to the third-party service platform as the interface provider, but instead initiates an authentication request to the interface provider through the connector after initiating a restful request. After the interface provider that the client initiates the restful request is changed, it can also flexibly find the connector corresponding to the interface provider according to the created corresponding relationship, so that the corresponding authentication request and forwarding of the request message can be realized by replacing the client with the corresponding connector, and the authentication method and requirements of any third-party service platform can be realized through the configured connector, which realizes the flexible management of different third-party service platforms and improves the user experience of the client and the interface provider. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 A flow chart of a method for processing a service request provided by an embodiment of the present invention; Figure 2 A schematic diagram of a process for configuring a connector according to an embodiment of the present invention; Figure 3 A schematic diagram of a process for converting a request message into a first message content provided by an embodiment of the present invention; Figure 4 A schematic diagram of a process for configuring path parameters in a first configuration item of a connector provided by an embodiment of the present invention; Figure 5 A schematic diagram of a process for a connector according to an embodiment of the present invention to return a return message to a client; Figure 6 for Figure 5 Specific execution steps of step S52; Figure 7 A schematic diagram of the interaction between a service request processing device provided in one embodiment of the present invention, a client, and an interface provider. DETAILED DESCRIPTION

[0019] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can 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.

[0020] In the prior art, when a user calls an interface service of a third-party service platform through a client, the client first needs to initiate a service authentication-related authentication request to the third-party service platform, so that the third-party service platform can authenticate the legitimacy or authority of the service request initiated by the client. However, different third-party service platforms often require users to perform different authentication methods. In this regard, the first embodiment of the present invention provides a service request processing method, see Figure 1 , the method comprises the following steps:

[0021] Step S11: 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 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 a RESTful API interface, and the third-party service platform includes at least one of a common service platform on the market, a service platform customized by an enterprise, etc.

[0022] Step S12: receiving a request message, and sending the request message to the connector according to the corresponding relationship;

[0023] Step S13: 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.

[0024] Therefore, this embodiment is configured with corresponding connectors for different interface providers. When the client subsequently initiates a RESTful request to any interface provider, it only needs to call the connector corresponding to the interface provider to perform authentication requests and forward request messages, eliminating the client's operation of executing authentication requests for different interface providers, making the client unaware of the authorization and authentication process, thereby improving the user experience of the client and the interface provider.

[0025] It can be seen that the service request processing method provided in this embodiment, 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, thereby initiating an 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. In other words, the client in this embodiment does not need to make an authentication request related to service authentication to the third-party service platform as the interface provider, but instead initiates an authentication request to the interface provider through the connector after initiating a restful request. After the interface provider that 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 that the corresponding authentication request and request message forwarding can be realized by replacing the client with the corresponding connector, and the authentication method and requirements of any third-party service platform can be realized through the configured connector, which realizes the flexible management of different third-party service platforms and improves the user experience of the client and the interface provider.

[0026] The connector can forward the request message to the interface provider by requesting a Proxy. A Proxy, also known as a network proxy, is a special network service that allows a network terminal (usually a client) to establish an indirect connection with another network terminal (usually a server) through this service. Some network devices such as gateways and routers have network proxy functions. It is generally believed that proxy services are beneficial to protecting the privacy or security of network terminals and preventing attacks. Therefore, the connector in this embodiment forwards the client's request message to the interface provider (such as a third-party service platform, server, etc.) through a 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.

[0027] Wherein, before executing the corresponding relationship between the pre-configured connector and the interface provider in step S11, the method provided in this embodiment includes the following steps: obtaining 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. Wherein, the interaction information is used to describe the information required for the client to interact with 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 the authentication rules for the interface provider to authenticate the service request initiated by the client and the key required for authentication based on the authentication rules, so that the connector initiates an authentication request to the interface provider based on the authentication information. The interaction information may specifically include the request protocol type, the root path of the request service, and the fixed service prefix CONTEXT of the request service; the request protocol type is used to indicate the protocol used by the connector to communicate with the target service, such as HTTP or HTTPS. 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 correctly and securely. The authentication rules in the authentication information describe how to verify the legitimacy of the restful request. In addition to the common basic authentication (Basic Auth), API key, Token authentication, Digest authentication (Digest authentication), OAuth authentication, etc., the authentication rules can also be other authentication rules customized for different enterprises.

[0028] Therefore, the connector obtained according to the interface document configuration in this embodiment can initiate an authentication request to the interface provider based on the authentication information through the configured connector corresponding to the requested interface provider when the client initiates a restful request to the corresponding interface provider, no matter what authentication rules the interface provider adopts. The authentication request process does not require the client to execute and participate, and the interface provider with different authentication rules can be flexibly managed, thereby improving the user's operating convenience and usage experience of the interface provider.

[0029] Among them, see Figure 2 , obtaining the interface document of the interface provider, and configuring the connector according to the interface document includes the following method steps:

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

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

[0032] 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 provider corresponding to the connector, the corresponding connector object can be operated and used at any time.

[0033] Therefore, after determining the configuration items required by the connector, this embodiment injects the interaction information and authentication information configuration in the parsed interface document into the corresponding configuration items to obtain the original resource file package of the connector. Subsequently, it only needs to load the resource file package and instantiate it to provide the client with authentication request and request message forwarding services.

[0034] When this embodiment injects the interaction information and authentication information configuration in the interface document into the corresponding configuration items, 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 rules and keys of the authentication information are injected into the second configuration item, so that the connector can perform the authentication request operation according to the information in the second configuration item. This embodiment can ensure that the connector dynamically obtains and uses the corresponding information at runtime by directly injecting the corresponding information into the corresponding configuration item, without the need to hard-code the interaction information and authentication information, thereby improving the flexibility of the connector to adapt to different environments and needs. Secondly, it is also convenient to modify and maintain the corresponding information. When the address, port and other information of the target interface provider changes, it is only necessary to modify the information of the corresponding configuration item in the resource file package without modifying the code.

[0035] In step S23, the step of loading the resource file package to obtain the connector includes: using a class loader to hot load the resource file package. Hot loading is a mechanism widely used in software development and operation and maintenance, which allows developers to update or replace code, data or configuration files without interrupting the operation 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 reloads the class file at runtime so that the changed code can take effect immediately. Therefore, this embodiment hot loads the resource file package, and subsequently, as long as the resource file package of the configured corresponding interface provider is obtained, the corresponding connector can be obtained and used in real time, and then the corresponding authentication request, forwarding request message and other operations are executed through the connector. When the 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.

[0036] In this embodiment, the step of obtaining the interface document of the interface provider to configure the connector according to the interface document 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 (full name ServiceProviderInterface, referred to as SPI) allows the application to dynamically load and discover providers (such as the interface provider that provides the interface document in this embodiment) at runtime, and interact with them, thereby realizing the decoupling of the application and the service provider. SPI is very suitable for the development of the connector plug-in, improving the dynamic configuration and use efficiency of the connector. Specifically, when the service discovery mechanism is used to develop the connector in this embodiment, only one template method needs to be developed. The input parameter of the connector is the request message of the client (or the first message content after conversion 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 in response to the request message. The plug-in for developing the connector is uploaded and loaded by packaging it into an independent resource file package Bundle. When loading, it can be hot loaded by URLClassLoader (URL class loader), and then instantiated by the service discovery mechanism.

[0037] In this embodiment, the development of the connector plug-in based on the service discovery mechanism 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, port, etc.) in the interface document of the interface provider during 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 is always connected to a healthy and available service instance, thereby improving the overall availability of the system.

[0038] Specifically, in some embodiments of the present invention, the restful request service performed by the client using the restful protocol is based on the HTTP protocol, and information is exchanged through request messages in the JSON data format. For the proxy forwarding of requests, commonly used open source tool components such as Apache HTTP Component, OK-HTTP and other tools can be used to initiate and receive requests. For most scenarios, it is only necessary to configure the protocol type, request method, common authentication rules and other information related to the restful request to complete the forwarding of the request. For 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 needs, it is necessary to use a customized connector plug-in for such interface providers to perform authentication requests and forward request messages.

[0039] In this regard, the connector plug-in type in this embodiment may specifically include a first connector and a second connector. The first connector is a connector set for a customized interface provider, and the second connector is a built-in HTTP general connector. The common basic authentication, API key, Token authentication, Digest authentication, OAuth authentication and other authentication rules configured by most interface providers can be configured in the second configuration item of the HTTP general connector to cover 70% of business scenarios. If the authentication request (i.e., authentication) cannot be implemented through the HTTP general connector, the first connector is introduced to implement the Proxy forwarding and response of the request message.

[0040] The HTTP universal connector in this embodiment can provide powerful service forwarding configuration content, and its configurable content includes: Request protocol: including HTTP and HTTPS; Root path of request service: configured in array mode. Multiple paths can be configured. Multiple paths can achieve load balancing on the interface provider side. CONTEXT of the requested service: the fixed service prefix of the interface provider; Common authentication methods for services: including Basic authentication, Token authentication, Digest authentication, etc. The number of abnormal retries of the service: the default is 1, and the number of abnormal retries can be customized to 2, 3, etc., which is not limited in this embodiment; Based on the above, the configuration items of HTTP universal connector may include the following: { "protocol": "http", / / Request protocol type "host": ["example1.com", "example2.com"], / / Root path of the requested service "contenxt": " / example-content", / / CONTEXT of the requested service "authType": "basic", / / Service authentication method "username": "example-user", / / username "password": "********" / / password } The request protocol type, the root path of the request service, the CONTEXT of the request service and other information are the configuration content of the first configuration item of the HTTP universal connector, and the service authentication method (such as Basic authentication), user name, password and other information are the configuration content of the second configuration item. Therefore, this embodiment can use the HTTP universal connector to perform authentication requests and forward request messages for 70% of business scenarios.

[0041] For some enterprise-customized interface providers that serve as third-party service platforms, due to differences in authentication forms and forwarding methods, the first connector can be used to forward authentication requests and request messages.

[0042] The first connector developed in this embodiment for an authentication form different from the common authentication rules can be configured according to the authentication information configured by the interface provider. The following are the contents of the configuration items of the first connector: { "protocol": "https", / / Request protocol type "host": ["example1.com", "example2.com"], / / Root path of the requested service "contenxt": " / example-content", / / CONTEXT of the requested service "token": "example-token", / / Service fixed token "secret": "example-secret" / / Secret key } The information including the request protocol type, the root path of the requested service, the CONTEXT of the requested service, etc. is the content of the first configuration item of the first connector. The configured service fixed token and key, etc. is the content of the second configuration item of the first connector. The corresponding authentication information varies according to the authentication rules and keys specified by the specific interface provider. For example, if the service fixed tokens of any two interface providers are the same but the keys are different, the contents of the key parts of different first connectors are configured as the key contents 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 will modify the configuration item position of the service fixed token to the authentication rules specified by the interface provider.

[0043] Therefore, this embodiment can perform plug-in expansion of some enterprise or other user-specific authentication information by setting up two plug-ins, the first connector and the second connector, according to the different interface providers that the client wants to request. The authentication request and the forwarding of the request message are executed through the corresponding connector, thereby realizing flexible management of different interface providers. There is no need for the client to initiate an authentication request to any interface provider, thereby improving the user experience of the interface provider.

[0044] Usually, the request message of the client is a message in the JSON data format. In order to avoid the situation that 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: determine the syntax format of the development language supported by the interface provider, convert the request message into the first message content based on the syntax format of the development language, and send the first message content to the connector to forward the first message content to the interface provider through the connector. In other words, this embodiment can send the converted first message content to the connector to forward the first message content to the interface provider through the connector, so as to avoid the situation that the interface provider cannot respond due to the request message being transparently transmitted (i.e., transparent transmission, a communication method that transmits data intact).

[0045] See also 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 grammatical format of the development language, the method provided in this embodiment also includes the following method steps:

[0046] Step S31: Determine the request feature of the request message, 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. If the request header (HTTP Header) is accept-ranges: bytes, cache-control:max-age=31536000, its first field name includes 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. 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 the cookie includes token=eyJ0eXAi, userId=123, username=admin, etc. The first field value of the cookie is a key-value pair, and two adjacent key-value pairs are separated by a separator ";". For example, the key of the first field value of token=eyJ0eXAi is token, and the value is eyJ0eXAi. A first field name can have one or more first field values, depending on the type of different request features.

[0047] Step S32: Split the content of the request feature according to the first splitting rule to obtain the first intermediate message content, 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. In this method step, if the request header is accept-ranges:bytes, cache-control:max-age=31536000, the content of the request header is split into multiple lines according to different first field names to obtain the following content: { "_HEADER": { "accept-ranges": "bytes", "cache-control": "max-age=31536000" } } For example, if 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: { "_Cookie": { "token": "eyJ0eXAi", "userId": "123", "username": "admin" } } In the first intermediate state message content, the content of each split request feature starts with "{" and ends with "}". 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 set and written in "{}" accordingly. 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 value of each line are also separated by a colon ":".

[0048] Step S33: converting the first intermediate message content into the first message content based on the grammatical format of the development language.

[0049] The forwarding of the request message can convert the client's request message into the message format required by the third-party service platform. The specific configurable request features are as follows:

[0050] Request response header, use the variable ${_HEADER.var}.

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

[0052] To access the path variable, use the variable ${_PATH.var}.

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

[0054] Request Body variables (Body parameters in POST values), use ${$.var}.

[0055] The data structure after each request feature is split according to the first splitting rule is set as an intermediate, and each intermediate is shown in Table 1: Table 1

[0056] The content of the first intermediate state message obtained by merging the data structures (i.e., intermediates) after splitting different request features is as follows: { "_HEADER": { "accept-ranges": "bytes", "cache-control": "max-age=31536000" }, "_Cookie": { "token": "eyJ0eXAi", "userId": "123", "username": "admin" }, "_PATH": { "entity": "user", "id": "123" }, "_PARAMETER": { "a": ["1", "2"], "b": "1" }, "username": "admin", "address": ["address1", "address2"] } The first intermediate state message content of the above structure is easy to parse and read, which can reduce the pressure of the back-end conversion operation process.

[0057] Therefore, the method provided in this embodiment can obtain the first intermediate state message content after splitting the request feature according to the first splitting rule before executing step S33. Since each line of data in the first intermediate state 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 in a separate line and when a first field name has multiple first field values, each first field value is in a separate line. In this way, the content of the corresponding request feature becomes clearer and easier to read, which can reduce the complexity of the data parser's parsing of the request feature, and make parsing errors easier to locate and correct. It has high flexibility and can greatly reduce the data parsing pressure when converting the request message into the first message content. In addition, if it is necessary to modify or add new fields, the line-by-line display method will make the modification and addition operations more direct and simple.

[0058] In this embodiment, the development language supported by the interface provider includes JSON path, which is a language used to query in JSON data. The step of converting the first intermediate message content into the first message content based on the grammatical format of the development language includes: adjusting the first intermediate message content according to the grammatical format of the JSON path to obtain the first message content.

[0059] The conversion of the request message uses the complete JSON Path syntax. If you need to use the value of the cache-control parameter in the request header as the forwarding input parameter, you can define it as ${HEADER.cache-control}.

[0060] If you need to use the id parameter in the request path as the forwarding input parameter, you can define it as ${_PATH.id}.

[0061] If you need to use parameter a in the request parameter as the input parameter, you can define it as ${_PARAMETER.a}.

[0062] If you need to use the first value of parameter a in the request parameter as the input parameter, you can define it as ${_PARAMETER.a[0]}.

[0063] If you need to use the username parameter in the Body field (request body) as the input parameter, you can define it as ${$.username} or ${username}.

[0064] 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 POST, GET, DELETE and other methods. 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.

[0065] Therefore, this embodiment converts the request message into the first intermediate state message content of an intermediate state structure, and then performs logic for taking values ​​(including expression calculation) on the first intermediate state message content to realize the content format conversion between the request message and the first message content, so as to more flexibly adapt to the corresponding interface provider and avoid the situation where the interface provider fails to respond.

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

[0067] Step S41: parse out the path parameters configured by the client in the request path, where the path parameters are the parameters required by the connector to route to the target service interface of the interface provider.

[0068] Step S42: configure the path parameter into the first configuration item, so that the connector calls the target service interface based on the first configuration item, so that the connector makes an authentication request to the target service interface and sends a corresponding message to the target service interface.

[0069] Therefore, in this embodiment, 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 configure 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. In other words, the path required by the client to request the target service interface of the interface provider (such as a third-party service platform) will eventually 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}.

[0070] 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 client user needs to call the target service interface, the user only needs to put 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, / forword-url is called, and the path parameter is A. The connector actually calls the target service interface of / forword-url / A, thereby improving the convenience of client operation and further enhancing the user experience of the client and the interface provider.

[0071] In step S13, after the request message is forwarded to the interface provider through the connector, see Figure 5 , the method provided in this embodiment also includes the following steps: Step S51: receiving, through the connector, a return message generated by the interface provider in response to the request message; Step S52: 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. The return characteristics include at least one of the response header, response body, and Cookie.

[0072] Therefore, 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 executing the above step S52. Therefore, when the interface provider adjusts the return content, the client will not be unable to accurately identify it due to the adjustment of the return content. For example, if the interface provider normally returns id, and the interface provider subsequently adjusts the returned id to id1, this embodiment can adjust the return feature (id1) according to the predetermined return feature (id in this case) until the content of the return feature is consistent with the predetermined return feature, and finally return the id to the client. In this way, the user will not be directly aware of whether the interface provider has adjusted the content of the return message, which further improves the user experience.

[0073] The content of the returned feature is the message content in JSON data format. The content of the returned feature includes the second field name and the second field value belonging to the second field name. The content of the scheduled return feature includes the scheduled field name and the scheduled field value belonging to the scheduled field name. See Figure 6 In step S52, the step of adjusting the content of the return feature according to the predetermined return feature pre-defined by the client until the content of the return feature is consistent with the predetermined return feature includes:

[0074] Step S521: Split the content of the returned feature according to the second splitting rule to obtain the second intermediate message content, the second splitting rule including 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.

[0075] Step S522: 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. 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, adjust the second field value to id, and / or determine whether the second intermediate state message content has a second field name 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. 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, delete the second field name a in the return feature and its second field value from the second intermediate state message content.

[0076] 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, the second message content is sent to the client as a return message. If the client supports the JSON data format, the second intermediate state message content is adjusted to the JSON data format and the second message content obtained is returned to the client.

[0077] In step S523, when converting the second intermediate state message content into the second message content according to the data exchange format supported by the client, the following method may be specifically included: 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. The configuration 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:

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

[0079] Returns the cookie, using the variable ${C_Cookie.var}.

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

[0081] The conversion process first converts the second intermediate message content according to the second splitting rule, then converts the second intermediate 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.

[0082] The data structure after each returned feature is split according to the second splitting rule is set as an intermediate, and each intermediate is shown in Table 2: Table 2

[0083] After merging the intermediates of the returned features in Table 2, the content of the second intermediate state message obtained is as follows: { "_HEADER": { "content-type": "application / json", "cache-control": "no-cache, no-store, max-age=0, must-revalidate" }, "_Cookie": { "token": "eyJ0eXAi", "userId": "123", "username": "admin" }, "system":"EDIWEB" ,"queryType":"Collection card information" ,"queryName":"Collection card information query" ,"url":" / onesite / truckInfo / list" ,"userToken":"AAA" } 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.

[0084] From the above, it can be seen that the embodiment of the present invention provides a product design idea and technical implementation solution for the scenario where the third-party RESTful API interface cannot be managed through flexible configuration when the enterprise builds its own API interface service market. 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 request authentication when forwarding the third-party service. Based on the intermediate message content (i.e., the first intermediate message content and the second intermediate message content) and JSON PATH technology, flexible conversion of request messages and return messages is implemented. The supported conversion content includes HTTP Header, Cookie, PATH (path), Request Parameter, Request Body, Response Body and other message contents.

[0085] The second embodiment of the present invention also provides a service request processing device, see Figure 7, the device includes a service connection module and a service gateway. The service connection module is used to create a correspondence between a pre-configured connector and an interface provider, and 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 correspondence. The service connection module is also used to initiate an 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.

[0086] Therefore, the service request processing device provided in this embodiment can send the received request message to the connector according to the corresponding relationship after creating the corresponding relationship between the connector and the interface provider, thereby initiating an 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. In other words, the client in this embodiment does not need to make an authentication request related to service authentication to the third-party service platform as the interface provider, but instead initiates an authentication request to the interface provider through the connector after initiating a restful request. After the interface provider that 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 that the corresponding authentication request and forwarding of the request message can be realized by replacing the client with the corresponding connector, and the authentication method and requirements of any third-party service platform can be realized through the configured connector, which realizes the flexible management of different third-party service platforms and improves the user experience of the client and the interface provider.

[0087] The connector configured in the service request processing device unifies the configuration of a certain type of interface provider. A type of interface provider can be configured with multiple forwarding requests. A single forwarding request needs to be configured separately. The configurable contents of the forwarding request include:

[0088] Request path: The path that the client uses to request the service gateway is globally unified. As the client's request entry, the request path supports variables, which can be defined as / exmaple-url, / example-url / {user_id}.

[0089] Request method: The client requests the service gateway through forwarding service paths such as GET (GET is used to obtain information about specified resources from the interface provider), POST (POST is used to submit data to be processed to the interface provider), and DELETE (DELETE is used to delete specified resources on the interface provider).

[0090] The path for requesting a third-party service will eventually be the superposition of the host, context, and path configured in the connector 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 client user needs to call the target service interface, the user only needs to put 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, / forword-url is called, and the path parameter is A. The connector actually calls the target service interface of / forword-url / A, thereby improving the convenience of client operation and further improving the user experience of the client and the interface provider. The forwarded service path supports the variable of the path parameter, which can be defined as / forword-url, / forword-url / ${_PATH.user_id}, / forword-url / ${_PARAMETER.name}, and / forword-url / ${_BODY.record[0].name}.

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

[0092] Request timeout, the timeout response time for the client to request the service gateway.

[0093] The timeout period for requesting a third party, and the timeout period for forwarding a request by a third party service.

[0094] The number of retries for requesting a third-party service. The number of retries when a third-party service fails.

[0095] The forwarding request configuration defines some configuration information of the client requesting the service gateway and the service gateway forwarding the third-party service through the connector, thereby providing fixed rules for the service's Proxy forwarding and ensuring the orderly and stable operation of the overall device.

[0096] Among them, before the service connection module creates a correspondence 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 key required for authentication based on the authentication rules, so that the connector initiates an authentication request to the interface provider based on the authentication information. For the 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 repeated here.

[0097] Therefore, in this embodiment, the connector obtained by the service connection module according to the interface document configuration can initiate an authentication request to the interface provider based on the authentication information through the configured connector corresponding to the requested interface provider when the client initiates a restful request to the corresponding interface provider, no matter what authentication rules the interface provider adopts. The authentication request process does not require the client to execute and participate, and the interface provider with different authentication rules can be flexibly managed, thereby improving the user's operating convenience and usage experience of the interface provider.

[0098] like Figure 7 As shown, the service connection module is configured with the HTTP service universal connector, the first connector L1 and the first connector L2, etc. Among them, in the created corresponding relationship, if the HTTP service universal connector corresponds to the interface provider J1, the first connector L1 corresponds to the interface provider J2, and the first connector L2 corresponds to the interface provider J3. If the client initiates a restful request to the interface provider J1, the service connection module calls the HTTP service universal connector according to the corresponding relationship to initiate an authentication request to the interface provider J1, and then sends the request message to the interface provider J1. If the client initiates a restful request to the interface provider J2, the service connection module calls the first connector L1 according to the corresponding relationship to initiate an authentication request to the interface provider J2, and then sends the request message to the interface provider J2. Therefore, no matter which interface provider the client initiates a restful request to, the service connection module can call the corresponding connector to forward the authentication request and message, without the client having to perform cumbersome authentication operations, which greatly improves the user experience.

[0099] Among them, 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 can be specifically executed:

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

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

[0102] 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 provider corresponding to the connector, the corresponding connector object can be operated and used at any time.

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

[0104] When the interactive information and authentication information configuration in the interface document are injected into the corresponding configuration items in this embodiment, the request protocol type, root path, etc. of the interactive 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 rules and keys of the authentication information are injected into the second configuration item, so that the connector can perform the authentication request operation according to the information in the second configuration item. The service connection module can ensure that the connector dynamically obtains and uses the corresponding information at runtime by directly injecting the corresponding information into the corresponding configuration item, without the need to hard-code the interactive information and authentication information, thereby improving the flexibility of the connector to adapt to different environments and needs. Secondly, it is also convenient to modify and maintain the corresponding information. When the address, port and other information of the target interface provider changes, it is only necessary to modify the information of the corresponding configuration item in the resource file package without modifying the code.

[0105] The step of loading the resource file package by the service connection module to obtain the connector includes: hot loading the resource file package by using a class loader. Thus, the service connection module hot loads the resource file package, and subsequently, as long as the resource file package of the configured corresponding interface provider is obtained, the corresponding connector can be obtained and used in real time, and then the corresponding authentication request, forwarding message and other operations are executed through the connector, and the service request processing device can obtain the corresponding connector in real time without restarting the service.

[0106] The service connection module obtains the interface document of the interface provider to configure the connector according to the interface document, which may specifically include: using the 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 (full name ServiceProviderInterface, referred to as SPI) allows the application to dynamically load and discover providers (such as the interface provider that provides the interface document in this embodiment) at runtime, and interact with them, thereby realizing the decoupling of the application and the service provider. SPI is very suitable for the development of the connector plug-in, improving the dynamic configuration and use efficiency of the connector. Specifically, when the service connection module uses the service discovery mechanism to develop the connector, it only needs to develop a template method. The input parameter of the connector is the client's request message (or the first message content after conversion mentioned later). The request message includes HTTP Header, Request PATH, Request Parameter, RequestBody, etc. The return value is the return message generated by the interface provider in response to the request message. The plug-in for developing the connector is uploaded and loaded by packaging it into an independent resource file package Bundle. When loading, it can be hot loaded by URLClassLoader (URL class loader), and then instantiated by the service discovery mechanism.

[0107] The service connection module develops a connector plug-in based on the service discovery mechanism to 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, port, etc.) in the interface document of the interface provider at runtime. Even if the service instance on 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 is always connected to a healthy and available service instance, improving the overall availability of the system.

[0108] The connector plug-in type configured by the service connection module may specifically include a first connector and a second connector. For the specific configuration methods and contents of these two connectors, please refer to the contents provided in the first embodiment of the present invention, which will not be repeated here in this embodiment. The service connection module performs plug-in expansion of some enterprise or other user-specific internal authentication information by setting up two plug-ins, the first connector and the second connector, based on the different interface providers to be requested by the client, and executes authentication requests and forwards request messages through corresponding connectors, thereby realizing flexible management of different interface providers, without the need for the client to initiate authentication requests to any interface provider, thereby improving the user experience of the interface provider.

[0109] Usually, the request message of the client is a message in the JSON data format. In order to avoid the situation that some interface providers cannot recognize the request message, the device in this embodiment also 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, so as to forward the first message content to the interface provider through the connector. In other words, this embodiment can send the converted first message content to the connector through the first message converter, so as to forward the first message content to the interface provider through the connector, so as to avoid the situation that the interface provider cannot respond due to the transparent transmission of the request message.

[0110] 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 through the first message converter based on the grammatical format of the development language, 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 type of the request characteristics includes at least one of the request header, request path, request parameters, body field, and cookie field. The service gateway obtains the first intermediate state message content after splitting the content of the request characteristics according to the first splitting rule. 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. The service gateway converts the first intermediate state message content into the first message content through the first message converter based on the grammatical format of the development language.

[0111] Therefore, the service gateway provided in this embodiment first splits the request feature according to the first splitting rule to obtain the first intermediate state message content before the first message converter executes step S33. Since each line of data in the first intermediate state message content has only one first field name and its first field value, and / or each line has different field values ​​for the same first field name, that is, each first field name and its corresponding first field value are in a separate line and when a first field name has multiple first field values, each first field value is in a separate line. In this way, the content of the corresponding request feature becomes clearer and easier to read, which can reduce the complexity of the first message converter's analysis of the request feature, and make it easier to locate and correct the analysis errors. 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. In addition, if it is necessary to modify or add new fields, the line-by-line display method will make the modification and addition operations more direct and simple.

[0112] In this embodiment, the development language supported by the interface provider includes JSON path, which is a language used to query in JSON data. The step of converting the first intermediate message content into the first message content based on the grammatical format of the development language by the first message converter includes: adjusting the first intermediate message content according to the grammatical format of the JSON path to obtain the first message content.

[0113] The conversion of the request message uses the complete JSON Path syntax. If you need to use the value of the cache-control parameter in the request header as the forwarding input parameter, you can define it as ${HEADER.cache-control}.

[0114] If you need to use the id parameter in the request path as the forwarding input parameter, you can define it as ${_PATH.id}.

[0115] If you need to use parameter a in the request parameter as the input parameter, you can define it as ${_PARAMETER.a}.

[0116] If you need to use the first value of parameter a in the request parameter as the input parameter, you can define it as ${_PARAMETER.a[0]}.

[0117] If you need to use the username parameter in the Body field (request body) as the input parameter, you can define it as ${$.username} or ${username}.

[0118] 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 POST, GET, DELETE and other methods. 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.

[0119] Therefore, after the service gateway converts the request message into the first intermediate state message content of an intermediate state structure, it then performs logic to take values ​​(including expression calculation) on the first intermediate state message content to implement content format conversion between the request message and the first message content, so as to more flexibly adapt to the corresponding interface provider and avoid the situation where the interface provider fails to respond.

[0120] Secondly, when the request feature in this embodiment includes a request path, before the service gateway splits the content of the request feature according to the first splitting rule to obtain the first intermediate message content, 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. 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.

[0121] Therefore, in this embodiment, 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. In other words, the path required by the client to request the target service interface of the interface provider (such as a third-party service platform) will eventually be the path information formed by the superposition combination of the root path host, the fixed service prefix CONTEXT, and the path parameters configured in the first configuration item of the connector.

[0122] 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 the response header, response body, and Cookie.

[0123] Therefore, before the service connection module sends a return message to the client, the connector can perform the above steps 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 identify it due to the adjustment of the return content. For example, if the interface provider normally returns an id, and the interface provider subsequently adjusts the returned id to id1, the service connection module can adjust the return feature (id1) according to the predetermined return feature (here is id) until the content of the return feature is consistent with the predetermined return feature, and finally return the id to the client. In this way, the user will not be directly aware of whether the interface provider has adjusted the return message content, which further improves the user experience.

[0124] 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, and the content of the predetermined return feature includes a predetermined field name and a predetermined field value belonging to the predetermined field name. The device in this embodiment also includes a second message converter, and the connector adjusts the content of the return feature according to the predetermined return feature pre-defined by the client until the content of the return feature is consistent with the predetermined return feature. The step includes: splitting the content of the return feature according to the second splitting rule to obtain the second intermediate state message content, and the second splitting rule includes a rule of splitting into multiple lines according to different second field names, and / or, 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. If not, adjust the second field value to the predetermined field value. If the predetermined field value is id and the second field value is id1, adjust the second field value to id, and / or, determine whether the second intermediate state message content has a second field name 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. After the connector converts the second intermediate state message content into the second message content according to the data exchange format supported by the client through the second message converter, the second message content is sent to the client as a return message through the service gateway. If the client supports the JSON data format, the second message content obtained after adjusting the adjusted second intermediate state message content to the JSON data format can be returned to the client.

[0125] When the second message converter converts the second intermediate state message content into the second message content according to the data exchange format supported by the client, the following method steps can be specifically performed: the request message conversion configuration is a conversion of the client message to the interface provider message, and the response message conversion is a conversion of the return message of the configuration interface provider response to the client message. Its configuration 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 a carrier in the form of Body, response header, and Cookie. The specific configurable content includes:

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

[0127] Returns the cookie, using the variable ${C_Cookie.var}.

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

[0129] The conversion process first converts the second intermediate message content according to the second splitting rule, then converts the second intermediate 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.

[0130] The data structure after each return feature is split according to the second splitting rule is set as an intermediate, and each intermediate is shown in Table 2 in the first embodiment. After the intermediates of each return feature in Table 2 are merged, the second intermediate state message content is obtained.

[0131] Therefore, the device provided in this embodiment not only realizes the adaptive adjustment and configuration of the return message, but also, before adjusting the content of the return message, firstly splits the return feature of the return message 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 of 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 ​​of 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, then the content of the corresponding return feature becomes clearer and easier to read, which can reduce the difficulty of adjusting and deleting the relevant second field values ​​and the second field names, thereby greatly reducing the conversion pressure of the second message converter when converting the return message into the second message content.

[0132] From the above, it can be seen that the embodiment of the present invention provides a product design idea and technical implementation solution for the scenario where the third-party RESTful API interface cannot be managed through flexible configuration when the enterprise builds its own API interface service market. 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 request authentication when forwarding the third-party service. Based on the intermediate message content (i.e., the first intermediate message content and the second intermediate message content) and JSON PATH technology, flexible conversion of request messages and return messages is implemented. The supported conversion content includes HTTP Header, Cookie, PATH (path), Request Parameter, Request Body, Response Body and other message contents.

[0133] When the interface provider is a third-party service platform, after the service request processing device provided in this embodiment is configured, it can conduct online client authentication request and message forwarding test (request message and return message) to the third-party service platform through the connector, and release it to the production state after the test is completed.

[0134] After a single forwarding service is configured, the service request processing device can provide an online debugging function. The service request processing device inputs the 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 capability of the third-party service platform in a configured manner. After the test is OK, you can click the publish button to publish it to the production environment for the client to call. The authentication request, current limiting, and fuse called by the client can all be managed uniformly by the service request processing device.

[0135] The key point of the embodiment of the present invention is the flexible service authentication plug-in system, which realizes flexible authentication adaptation of the interface provider through the built-in HTTP universal connector and the plug-in connector that can be dynamically uploaded and loaded. At the same time, based on the characteristics of the restful protocol and the HTTP protocol, by using the universal configuration method of the JSON PATH expression and the JSON data format, the content conversion of the request message and the return message can be easily realized without special technical thresholds.

[0136] This embodiment uses a connector configured by a plug-in mechanism (such as a custom-developed first connector and a built-in HTTP universal connector) to achieve management of any authentication method of the interface provider and message forwarding. This management method is efficient and has low configuration difficulty.

[0137] Based on the concept of connector plug-in, there is no need to customize the application to shield the authentication information required for the authentication of the interface provider (such as a third-party service platform), nor is there a need for hard coding or scripting languages ​​to implement the authentication information assembly of the interface provider. This enables a type of interface provider to be configured or customized once, and multiple services to forward multiple configurations.

[0138] Based on HTTP protocol Header, Cookie, Request Paramter and RESTful protocol RequestBody, Response Body messages, only widely used JSON PATH expressions are used, and flexible conversion and adaptation of message content can be achieved without introducing scripting languages, customizing DSL, etc. Cookie is a small data fragment used to track and save user information.

[0139] In some embodiments of the present invention, the service gateway can be used only for service forwarding, and the authentication information is solved by the microservice application itself, such as configuring the routing forwarding strategy of the three-party request based on the service gateway, and each three-party service platform customizes a microservice application to realize the decoding of the authentication information and the forwarding of the protocol content, that is, each platform customizes a microservice implementation. Flexible authentication information assembly can also be achieved through a built-in scripting language, such as using an embedded Python scripting language to assemble authentication-related authentication information into a message header, message body, etc. when configuring the forwarding service, so as to realize a configured forwarding three-party service. For the forwarding of request and response messages, a certain degree of content conversion can be achieved by configuring field mapping, but the overall degree of configuration is not high. For flexible content message conversion, a three-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 returned after the processing is completed.

[0140] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in 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; The authentication request is initiated to the interface provider through the connector, and after the authentication request is passed, the request message is forwarded to the interface provider through the connector.

2. The service request processing method according to claim 1, characterized in that: 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; Among them, the interaction information is used to describe the information required for the client to interact with 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 the authentication rules for the interface provider to authenticate the service request initiated by the client and the key required for authentication based on the authentication rules, so that the connector initiates the authentication request to the interface provider based on the authentication information.

3. The service request processing method according to claim 2, characterized in that: 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; The resource file package is loaded to obtain the connector and instantiate the connector.

4. The service request processing method according to claim 3, 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.

5. The service request processing method according to claim 2, 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.

6. The service request processing method according to claim 3, characterized in that: 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.

7. The service request processing method according to claim 6, characterized in that: 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; The first intermediate message content is converted into the first message content based on the grammatical format of the development language.

8. The service request processing method according to claim 7, 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 syntax format of the JSON path to obtain the first message content.

9. The service request processing method according to claim 7, characterized in that: When the request feature includes the request path, before obtaining the first intermediate message content after splitting the content of the request feature according to the first splitting rule, 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; The path parameter is configured 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.

10. The service request processing method according to any one of claims 1 to 5, characterized in that: 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.

11. The service request processing method according to claim 10, 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 pre-defined 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.

12. 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 configured 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.

Images