Request processing method and device, medium and electronic equipment

Abstract

The invention relates to the technical field of data processing, and provides a request processing method and device, a medium and electronic device.The request processing method comprises the steps that the type name and request parameter information of a first request are determined, and the request parameter information comprises request parameters and request parameter values corresponding to the request parameters; according to the type name, target query type configuration is obtained from preset query type configuration, the target query type configuration is used for converting the first request into a second request, and endpoint architectures or communication mechanisms corresponding to the first request and the second request are different; replacing the parameter value of a target configuration item with the same name as the request parameter in the target query type configuration with the request parameter value to obtain a second request; and obtaining a processing result based on the second request. The request processing method can reduce the request processing cost and improve the request processing efficiency.

Description

Technical Field

[0001] The present disclosure relates to the technical field of data processing, and specifically, to a request processing method, apparatus, medium, and electronic device. Background Art

[0002] GraphQL is a query language for application programming interfaces (APIs). It allows clients to precisely specify the data they need, and the server returns data that exactly matches the request.

[0003] Representational State Transfer (REST) is a software architecture style for designing web applications. REST is based on the HTTP protocol and uses standard HTTP methods to operate on resources.

[0004] On the premise that REST service requests can already be processed, if one wants to process GraphQL service requests, developers still need to intervene and appropriately modify the service interface, which will increase the cost and reduce the efficiency of request processing. Summary of the Invention

[0005] The purpose of the present disclosure is to provide a request processing method, apparatus, medium, and electronic device to solve the above problems.

[0006] To achieve the above purpose, the present disclosure provides a request processing method, including:

[0007] Determine the type name and request parameter information of a first request, where the request parameter information includes request parameters and request parameter values corresponding to the request parameters;

[0008] According to the type name, obtain a target query type configuration in a preset query type configuration, where the target query type configuration is used to convert the first request into a second request, and the first request and the second request have different corresponding endpoint architectures or communication mechanisms;

[0009] Replace the parameter value of a target configuration item in the target query type configuration with the same name as the request parameter with the request parameter value to obtain a second request;

[0010] Based on the second request, obtain a processing result.

[0011] The present disclosure also provides a request processing apparatus, where the request processing apparatus includes:

[0012] A determination request module is configured to determine the type name and request parameter information of a first request, where the request parameter information includes request parameters and request parameter values corresponding to the request parameters.

[0013] A configuration acquisition module is configured to obtain a target query type configuration from a preset query type configuration according to the type name, where the target query type configuration is used to convert the first request into a second request, and the first request and the second request have different endpoint architectures or communication mechanisms.

[0014] A parameter replacement module is configured to replace the parameter value of a target configuration item in the target query type configuration with the same name as the request parameter with the request parameter value to obtain a second request.

[0015] A request acquisition module is configured to obtain a processing result based on the second request.

[0016] The present disclosure also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the steps of the above request processing method are implemented.

[0017] The present disclosure also provides an electronic device, including:

[0018] A memory, on which a computer program is stored;

[0019] A processor, configured to execute the computer program in the memory to implement the steps of the above request processing method.

[0020] Through the above technical solution, according to the type name of the first request, a target query type configuration is obtained from a preset query type configuration, and then according to the target query type configuration and the request parameter value corresponding to the request parameter of the first type, a second request that can adapt to the existing service interface is obtained, and then based on the second request, a processing result is obtained. Thus, it is possible to convert the first request configuration of the GraphQL service request into the second request of the existing REST service request without modifying the existing service interface to obtain the processing result corresponding to the first request. By performing configuration conversion, there is no need to modify the existing service interface, reducing the request processing cost and improving the request processing efficiency.

[0021] Other features and advantages of the present disclosure will be described in detail in the subsequent specific implementation part. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings are used to provide a further understanding of the present disclosure and constitute a part of the specification, and are used to explain the present disclosure together with the following specific implementation manners, but do not constitute a limitation to the present disclosure. In the drawings:

[0023] Figure 1 It is a flowchart of a request processing method shown according to an exemplary embodiment.

[0024] Figure 2 It is a schematic diagram of a preset query type configuration shown according to an exemplary embodiment.

[0025] Figure 3 It is a flowchart of sub - steps of step S3 shown according to an exemplary embodiment.

[0026] Figure 4 It is a flowchart of sub - steps of step S4 shown according to an exemplary embodiment.

[0027] Figure 5 It is another flowchart of sub - steps of step S4 shown according to an exemplary embodiment.

[0028] Figure 6 It is a flowchart of another request processing method shown according to an exemplary embodiment.

[0029] Figure 7 It is a flowchart of sub - steps of step S42 shown according to an exemplary embodiment.

[0030] Figure 8 It is a block diagram of a request processing device shown according to an exemplary embodiment.

[0031] Figure 9 It is a block diagram of an electronic device shown according to an exemplary embodiment. Detailed implementation manners

[0032] The following will describe the detailed implementation manners of the present disclosure in conjunction with the accompanying drawings. It should be understood that the detailed implementation manners described herein are only for the purpose of illustration and explanation of the present disclosure, and are not used to limit the present disclosure.

[0033] In the following description, terms such as "first" and "second" are only used for the purpose of distinguishing descriptions, and cannot be understood as indicating or implying relative importance, nor can they be understood as indicating or implying order.

[0034] GraphQL is a query language for APIs and also a runtime environment. It provides a clear and complete description of the data in the API, enabling the client to accurately obtain the required data and avoid redundancy. In addition, GraphQL also supports the flexible evolution of the API and provides powerful tools for developers. Its core goal is to provide a more efficient and flexible way of data querying to replace the traditional REST APIs.

[0035] When applying GraphQL to a project, the following steps are usually involved:

[0036] (1) Define the GraphQL Schema.

[0037] (2) Define the data model corresponding to the Schema.

[0038] (3) Write a controller to implement the logical mapping of the Schema.

[0039] (4) Develop a service implementation class to handle GraphQL requests.

[0040] However, there are some problems with this access method:

[0041] These steps are highly invasive to the application and have a high development cost.

[0042] Even if there is already an HTTP / REST service implementation in the project, certain modifications still need to be made. Specifically, steps (1) to (3) above need to be completed, and the existing service implementation class in step (4) needs to be appropriately adjusted.

[0043] Currently, HTTP / REST interfaces are very widely used in actual applications. If a GraphQL service is to be accessed on the basis of an existing HTTP / REST service, developers still need to intervene and make modifications, that is, they need to interface with other different types of service interfaces, usually requiring the re - construction of service interfaces, which not only increases the request processing cost but also reduces the efficiency.

[0044] In view of the above problems, the present invention proposes a solution:

[0045] According to the type name of the first request, obtain the target query type configuration in the preset query type configuration, and then, based on the target query type configuration and the request parameter values corresponding to the request parameters of the first type, obtain a second request that can adapt to the existing service interface. Then, based on the second request, obtain the processing result. Thus, it is possible to convert the first request configuration of the GraphQL service request into the second request of the existing REST service without modifying the existing service interface, so as to obtain the processing result corresponding to the first request. By performing the configuration conversion, there is no need to modify the existing service interface, reducing the request processing cost and improving the request processing efficiency.

[0046] Please refer to Figure 1 , Figure 1 which is a flowchart of a request processing method shown according to an exemplary embodiment. The request processing method can be applied to an electronic device and can include steps S1 to S4.

[0047] Step S1, determine the type name and request parameter information of the first request.

[0048] Among them, the request parameter information includes request parameters and request parameter values corresponding to the request parameters.

[0049] The first request can be a GraphQL service request.

[0050] The type name of the first request can be an operation type and / or an operation name. The operation type can be, for example, query, mutation, subscription, etc., and the operation name can be, for example, User, GetUserInfo, CreateUser, etc.

[0051] The request parameters can be the parameters that need to be conveyed in the request, and the request parameter values corresponding to the request parameters are the specific values specified for the request parameters.

[0052] Exemplarily, the request parameters can be "userId", "orderId", "pageSize", and the request parameter values can be, for example, "12345".

[0053] In one embodiment, the first request is query user(userId: "user1"). Among them, the type name is query user, the request parameter in the request parameter information is userId, and the request parameter value in the request parameter is user1.

[0054] Step S2, according to the type name, obtain the target query type configuration in the preset query type configuration.

[0055] Among them, the target query type configuration is used to convert the first request into a second request, and the endpoint architectures or communication mechanisms corresponding to the first request and the second request are different.

[0056] That the endpoint architectures of the first request and the second request are different can be understood as that the number of endpoints on which the first request and the second request depend is different. For example, the first request depends on the endpoint architecture of multiple endpoints, and the second request depends on the endpoint architecture of a single endpoint. Exemplarily, the first request can be a GraphQL service request, and the second request can be a REST service request.

[0057] That the communication mechanisms of the first request and the second request are different can be understood as that the first request depends on the communication mechanism between the client and the remote server, and the second request depends on the communication mechanism between the client and the local server. Exemplarily, the first request can be a GraphQL service request, and the second request can be a local call service request.

[0058] Multiple preset query type configurations are pre-stored. The preset query type configuration may include a type name configuration item for representing the type name, a uniform resource identifier (URI) configuration item for representing the data address, a method configuration item for representing the data processing method, a result path configuration item for extracting the result object from the response result, and a fields configuration list configuration item for recording the request attribute data interface information corresponding to the request parameters.

[0059] In the case where the second request is a local call service request, a new configuration item serviceMethod is added to replace the configuration item uri. Specifically, serviceMethod is used to configure the corresponding local service query method call, and the call parameters are separated by commas. In the corresponding interceptor implementation, the corresponding query method can be called through reflection to obtain the response result. The specific example of the corresponding target query type configuration is as follows:

[0060] YAML graphql:

[0061] query:

[0062] # Query 1 - Query user details

[0063] user:

[0064] serviceMethod:userServcie.getUserById({userId})

[0065] resultPath:$.data

[0066] fields:

[0067] # Query the department information associated with the user details

[0068] dept:

[0069] serviceMethod:deptService.getDeptById({user[$.data.deptId]})

[0070] resultPath:$.data

[0071] # Query the department name associated with the user details

[0072] deptName:

[0073] serviceMethod:deptService.getDeptById({user[$.data.deptId]})

[0074] resultPath: $.data.deptName

[0075] # Query the role list associated with user details

[0076] roles:

[0077] serviceMethod: roleService.getRolesByUserId({userId})

[0078] resultPath: $.data

[0079] According to the type name, obtain the target query type configuration in the preset query type configuration. It can be understood that the preset query type configuration corresponding to the type name that is the same as the type name of the first request among multiple preset query type configurations is determined as the target query type configuration, that is, the type name in the target query type configuration is the same as the type name of the first request.

[0080] Step S3, replace the parameter value of the target configuration item in the target query type configuration whose name is the same as the request parameter with the request parameter value to obtain the second request.

[0081] The second request can be a REST service request or a local call service request.

[0082] The target query type configuration includes multiple configuration items, and the configuration items may contain configuration parameters.

[0083] Exemplarily, the target query type configuration is:

[0084] user:

[0085] uri: / api / v1 / users / {userId}

[0086] resultPath: $.data fields: # Query the department information associated with user details

[0087] Among them, the multiple configuration items are uri, resultPath, and fields respectively. The configuration item that contains the configuration parameter is only uri, and its corresponding configuration item parameter is userId. The configuration items resultPath and fields do not contain configuration item parameters.

[0088] Compare the names of the configuration parameters of multiple configuration items in the target query type configuration with the names of the request parameters of the first request. When the name of the configuration parameter of one of the configuration items in the target query type configuration is the same as the name of the request parameter of the first request, determine this configuration item as the target configuration item, and replace the parameter value of this target configuration item with the request parameter value of the first request to obtain a second request.

[0089] Step S4, obtain a processing result based on the second request.

[0090] Send the second request to the database for data processing. The database feeds back a response result for the second request, and obtain the processing result of the first request according to this response result.

[0091] By obtaining the target query type configuration in the preset query type configuration according to the type name of the first request, and then obtaining the second request that can adapt to the existing service interface according to the target query type configuration and the request parameter value corresponding to the request parameter of the first type, and then obtaining the processing result based on the second request. In this way, it is possible to convert the first request configuration of the GraphQL service request into the second request of the existing REST service request without modifying the existing service interface to obtain the processing result corresponding to the first request. By performing configuration conversion, there is no need to modify the existing service interface, reducing the request processing cost and improving the request processing efficiency.

[0092] In a possible implementation manner, step S1 may include:

[0093] In response to receiving the first request, call the Web request interceptor to intercept the first request, and determine the type name and request parameter information of the first request.

[0094] When calling the Web request interceptor to intercept the first request, perform the subsequent request processing flow of determining the type name and request parameter information of the first request on the first request, and then convert the first request into the second request.

[0095] By setting the step of calling the Web request interceptor to intercept the first request in response to receiving the first request, that is, the first request is pre-intercepted before processing, to avoid the first request being directly sent to the database and unable to perform the subsequent request processing flow.

[0096] Next, the first request is a GraphQL service request and the second request is a REST service request for elaboration.

[0097] The Uniform Resource Identifier (URI) configuration item used to represent a data address can be a REST service URI. The method configuration item used to represent a data processing method can be a REST service Method. The result path configuration item used to extract a result object from a response result can be a result extraction path. The fields configuration list configuration item used to record the data interface information of the request attribute corresponding to a request parameter can be a fields list.

[0098] When the target query type configuration includes a URI configuration item, a second request can be generated according to this URI interface configuration item. When the target query type configuration includes a method configuration item, a service request can be generated according to this method configuration item to execute the data processing method in the method configuration item in the database, and then obtain the corresponding response result. When the target query type configuration includes a result path configuration item, data can be extracted starting from the position corresponding to the result extraction path in the response result to obtain the target result object. When the target query type configuration includes a fields configuration list configuration item, other interface configuration items can be called according to the data interface information of the request attribute corresponding to the request parameter, and then a corresponding service request can be generated.

[0099] In one embodiment, the configuration rule maps an HTTP / REST interface to a GraphQL query service. The configuration rule mainly consists of multiple preset query type configurations. Each preset query type configuration includes a type name, a REST service URI, a REST service Method, a result extraction path, and a fields configuration list. The specific configuration item descriptions of the query type configuration are shown in Table 1:

[0100] Table 1

[0101]

[0102]

[0103] Regarding the two parameter forms in the uri, the specific usage instructions are as follows:

[0104] Form 1: Request parameter: The specific content in {...} is the dynamic parameter name. For example, if the URI is configured as / users / {userId}, then {userId} indicates that the dynamic parameter name is userId, corresponding to the request parameter query user(userId: "specific userId parameter value") in GraphQL.

[0105] Form 2: Type result JsonPath attribute: If the specific content in {...} is in the format of typeName[JsonPath], it means that the parameter needs to be extracted through JsonPath from the response result of the specified REST query request corresponding to typeName in the current GraphQL request. For example, if the URI is configured as / api / v1 / depts / {user[$.data.deptId]}, then {user[$.data.deptId]} indicates that the dynamic parameter needs to be extracted from the response result of the previous REST request with typeName as user, and the extraction JsonPath is $.data.deptId.

[0106] If the result attribute of GraphQL is of array type, such as a list of user information (e.g., [User]), when configuring the department information associated with each user in the user information list, the query parameter for dept in the result of each user in the list can be configured as the deptId attribute corresponding to each user in the form of {user[$.data.list[*].deptId]}. During parsing, [*] will be automatically replaced by the current user index in the user array under data.list, such as [0], [1], etc. And it supports setting the parameter default value using the | symbol. For example, {pageSize|1} means that if no specific pageSize parameter is provided, the default value 1 will be used.

[0107] Please refer to Figure 2 , Figure 2 is a schematic diagram showing a preset query type configuration according to an exemplary embodiment. There may be other query type configurations nested under one query type configuration.

[0108] In a possible implementation, the target query type configuration includes a uniform resource identifier URI configuration item representing the data address and a method configuration item for the data processing method. Please refer to Figure 3 , step S3 may include step S31 and step S32.

[0109] Step S31, replace the parameter value of the URI configuration item in the target query type configuration whose name is the same as the request parameter with the request parameter value to obtain the target URI.

[0110] Compare the name of the configuration parameter of the URI configuration item in the target query type configuration with the request parameter of the first request. When the name of the configuration parameter of the URI configuration item in the target query type configuration is the same as the name of the request parameter of the first request, determine the URI configuration item as the target configuration item, and replace the parameter value of the target configuration item with the request parameter value to obtain the target URI.

[0111] Exemplarily, the URI configuration item is: / api / v1 / users / {userId}. After replacing the parameter value, the target URI is: / api / v1 / users / user1.

[0112] Step S32: Obtain a second request according to the target URI and the method configuration item.

[0113] Exemplarily, adding the method configuration item before the target URI can obtain the second request.

[0114] The method configuration item can be, but is not limited to, obtaining data (GET), creating data (POST), updating or replacing data (PUT), partially updating data (PATCH), deleting data (DELETE), etc.

[0115] Exemplarily, if the method configuration item is to obtain data GET, then the second request is GET / api / v1 / users / user1.

[0116] In a possible implementation manner, please refer to Figure 4 , step S4 may include steps S41 to S43.

[0117] Step S41: Send the second request to the database for data processing.

[0118] It should be understood that in the case where the second request is a REST service request, the corresponding database is the database deployed on the remote server. In the case where the second request is a local call service request, the corresponding database is the database deployed on the local server.

[0119] Step S42: After receiving the response result feedback by the database for the second request, extract the result attribute from the response result, and compare the result attribute with the request attribute corresponding to the request parameter in the first request.

[0120] The result attribute can be a logical or semantic representation used to characterize the specific data fields in the response result.

[0121] Exemplarily, if the response result is:

[0122]

[0123] Among them, the result attribute may include code, msg, and id, deptCode, deptName, deptDesc, parentDeptCode in data.

[0124] The request attribute can be a logical or semantic representation used to characterize the specific data fields that the request parameter in the first request wants to obtain.

[0125] Exemplarily, the first request is:

[0126]

[0127]

[0128] Among them, the request attributes may include the id in user, userAccount, deptId, deptName, the id in dept, deptCode, deptName, roleIds, the id in roles, roleCode, roleName.

[0129] The database deployed on the remote server / local server generates a response result for the second request, and feeds the response result back to the electronic device. Then the electronic device extracts the result attributes of the response result, and compares the result attributes of the response result with the request attributes corresponding to the request parameters in the first request.

[0130] It should be understood that comparing the result attributes of the response result with the request attributes corresponding to the request parameters in the first request can be understood as traversing each result attribute in the response result, and respectively comparing each result attribute with all the request attributes corresponding to the request parameters in the first request to determine whether each result attribute is the same as one of the request attributes corresponding to the request parameters in the first request.

[0131] Step S43, when the result attribute is the same as the request attribute, determine the result attribute value corresponding to the result attribute as the first processing result subset, and the processing result includes the first processing result subset.

[0132] When one of the result attributes in the result attributes is the same as one of the request attributes in the first request, determine the result attribute value corresponding to the result attribute as the first processing result subset.

[0133] Exemplarily, the result attributes include code, msg, and id, deptCode, deptName, deptDesc, parentDeptCode in data. The request attributes include id, userAccount, deptId, deptName in user, id, deptCode, deptName in dept, roleIds, and id, roleCode, roleName in roles. By comparison, it can be seen that the result attribute values corresponding to id, deptCode, and deptName in the result attributes are "dept1", "deptRoot", and "Headquarters" respectively. These three result attribute values are the first processed result subset.

[0134] In a possible implementation, the target query type configuration includes a fields configuration list, and the fields configuration list is used to record at least one interface configuration item other than the target configuration item. The call interface corresponding to the target configuration item is different from the call interface corresponding to the interface configuration item.

[0135] The interface configuration item can be other configuration items related to the target configuration item, and the call interface corresponding to the interface configuration item is different from the call interface corresponding to the target configuration item.

[0136] Next, a specific example is used to introduce the interface configuration items in the fields configuration list.

[0137] Exemplarily, the target query type configuration is as follows:

[0138] YAML graphql:

[0139] query:

[0140] # Query 1 - Query user details

[0141] user:

[0142] uri: / api / v1 / users / {userId}

[0143] resultPath:$.data

[0144] fields:

[0145] # Query the department information associated with the user details

[0146] dept:

[0147] uri: / api / v1 / depts / {user[$.data.deptId]}

[0148] resultPath: $.data

[0149] # Query the department name associated with the user details

[0150] deptName:

[0151] uri: / api / v1 / depts / {user[$.data.deptId]}

[0152] resultPath: $.data.deptName

[0153] # Query the list of roles associated with the user details

[0154] roles:

[0155] uri: / api / v1 / roles / {userId}

[0156] resultPath: $.data

[0157] Among them, the fields configuration list is as follows:

[0158] fields:

[0159] # Query the department information associated with the user details

[0160] dept:

[0161] uri: / api / v1 / depts / {user[$.data.deptId]}

[0162] resultPath: $.data

[0163] # Query the department name associated with the user details

[0164] deptName:

[0165] uri: / api / v1 / depts / {user[$.data.deptId]}

[0166] resultPath: $.data.deptName

[0167] # Query the list of roles associated with the user details

[0168] roles:

[0169] uri: / api / v1 / roles / {userId}

[0170] resultPath: $.data

[0171] The interface configuration items recorded in the fields configuration list are respectively:

[0172] ① dept:

[0173] uri: / api / v1 / depts / {user[$.data.deptId]}

[0174] resultPath: $.data

[0175] ② deptName:

[0176] uri: / api / v1 / depts / {user[$.data.deptId]}

[0177] resultPath: $.data.deptName

[0178] ③ roles:

[0179] uri: / api / v1 / roles / {userId}

[0180] resultPath: $.data

[0181] The corresponding call interfaces are dept, deptName, and roles respectively, which are different from the call interface user corresponding to the target configuration item.

[0182] Please refer to Figure 5 , and the request processing method may further include steps S44 to S46.

[0183] Step S44, find the result attribute in the fields configuration list.

[0184] Finding the result attribute in the fields configuration list can be understood as, for each result attribute, finding the result attribute in the fields configuration list and determining whether the result attribute is in the fields configuration list.

[0185] Step S45, if the result attribute is found in the fields configuration list, then replace the parameter value of the interface configuration item corresponding to the result attribute in the fields configuration list with the result attribute value corresponding to the result attribute, to obtain the third request.

[0186] The third request may be a REST service request.

[0187] Replace the parameter value of the interface configuration item corresponding to the result attribute in the fields configuration list with the result attribute value corresponding to the result attribute, and a third request can be obtained. It can be understood that after replacing the parameter value of the interface configuration item corresponding to the result attribute in the fields configuration list with the result attribute value corresponding to the result attribute, and then combining with the method configuration item, a third request is obtained.

[0188] For example, if a result attribute is deptId and its corresponding result attribute value is dept1, and this result attribute exists in both the interface configuration items corresponding to the interfaces dept and deptName, then substitute the result attribute value dept1 into the corresponding interface configuration items, and then combine with the method configuration item to obtain the data GET, and a third request is obtained:

[0189] GET / api / v1 / depts / dept1

[0190] GET / api / v1 / deptName / dept1.

[0191] Step S46, based on the third request, obtain a second subset of processing results, and the processing results also include the second subset of processing results.

[0192] Send the third request to the database for data processing, and the database feedbacks a response result for the third request, and obtain a second subset of processing results according to this response result.

[0193] For example, the target query type configuration is:

[0194] YAML

[0195] graphql:

[0196] query:

[0197] #Query 1 - Query user details

[0198] user:

[0199] uri: / api / v1 / users / {userId}

[0200] resultPath:$.data

[0201] fields:

[0202] #Query the department information associated with the user details

[0203] dept:

[0204] uri: / api / v1 / depts / {user[$.data.deptId]}

[0205] resultPath: $.data

[0206] # Query the department name associated with the user details

[0207] deptName:

[0208] uri: / api / v1 / depts / {user[$.data.deptId]}

[0209] resultPath: $.data.deptName

[0210] # Query the list of roles associated with the user details

[0211] roles:

[0212] uri: / api / v1 / roles / {userId}

[0213] resultPath: $.data

[0214] Among them, the fields configuration list is as follows:

[0215] fields:

[0216] # Query the department information associated with the user details

[0217] dept:

[0218] uri: / api / v1 / depts / {user[$.data.deptId]}

[0219] resultPath: $.data

[0220] # Query the department name associated with the user details

[0221] deptName:

[0222] uri: / api / v1 / depts / {user[$.data.deptId]}

[0223] resultPath: $.data.deptName

[0224] # Query the list of roles associated with the user details

[0225] roles:

[0226] uri: / api / v1 / roles / {userId}

[0227] resultPath: $.data

[0228] The interface configuration items recorded in the fields configuration list are as follows:

[0229] ④ dept:

[0230] uri: / api / v1 / depts / {user[$.data.deptId]}

[0231] resultPath: $.data

[0232] ⑤ deptName:

[0233] uri: / api / v1 / depts / {user[$.data.deptId]}

[0234] resultPath: $.data.deptName

[0235] ⑥ roles:

[0236] uri: / api / v1 / roles / {userId}

[0237] resultPath: $.data

[0238] The corresponding call interfaces are dept, deptName, and roles respectively, which are different from the call interface user corresponding to the target configuration item.

[0239] In one embodiment, first send the third request to the database for data processing. After receiving the response result feedback by the database for the third request, extract the result attributes from the response result, and compare the result attributes with the request attributes corresponding to the request parameters in the first request. When the result attributes are the same as the request attributes, determine the result attribute value corresponding to the result attributes as the second processing result subset.

[0240] It should be understood that the process of obtaining the second processing result subset based on the third request can refer to the process of obtaining the first processing subset based on the second request, which will not be elaborated herein in this embodiment.

[0241] It should be noted that steps S44 to S46 can be executed after steps S41 to S43, or steps S44 to S46 can also be directly connected and executed after "after receiving the response result feedback by the database for the second request, extract the result attributes" in step S42, that is, "compare the result attributes with the request attributes corresponding to the request parameters in the first request" in step S42 is executed after steps S44 to S46, or both are executed simultaneously.

[0242] In one embodiment, please refer to Figure 6 , Figure 6 which is a flowchart of another request processing method shown according to an exemplary embodiment. This request processing method can be applied to an electronic device, and this request processing method may include steps S201 to S210.

[0243] Step S201, determine the type name, request parameters, and request parameter values of the first request.

[0244] Step S202, determine the target query type configuration according to the type name.

[0245] Step S203, replace the configuration item parameter values.

[0246] It should be understood that if replacing the configuration item parameter values in the target query type configuration, it means replacing the parameter values of the target configuration item with the same name as the request parameter in the target query type configuration with the request parameter values; if replacing the configuration item parameter values in the interface configuration item corresponding to the result attribute, it means replacing the parameter values of the interface configuration item corresponding to the result attribute in the fields configuration list with the result attribute values corresponding to the result attributes.

[0247] Step S204, generate a REST query request, and record the response result and the target result object.

[0248] In the case where the replaced configuration item parameter values are the configuration item parameter values in the target query type configuration, the corresponding generated REST query request is the second request.

[0249] In the case where the replaced configuration item parameter values are the configuration item parameter values in the interface configuration item, the corresponding generated REST query request is the third request.

[0250] Step S205, traverse the result attributes.

[0251] Step S206, determine whether the result attribute is in the fields configuration list.

[0252] If not, that is, the result attribute is not in the fields configuration list, then execute step S207.

[0253] If so, that is, the result attribute is in the fields configuration list, then execute step S208.

[0254] Step S207, use the result attribute values corresponding to the result attributes that are the same as the request attributes as the subset of the processing results.

[0255] Compare the result attribute with the request attribute corresponding to the request parameter in the first request to determine whether the result attribute is the same as one of the request attributes corresponding to the request parameter in the first request, and use the result attribute value corresponding to the result attribute that is the same as the request attribute as the processed result subset.

[0256] It should be understood that if the result attribute is obtained from the feedback of the second request generated based on the interface configuration item dept, then the result attribute should be compared with the request attribute under dept in the request parameter of the first request, so as to achieve the comparison between the result attribute and the request attribute at the same level. Step S208, determine the interface configuration item corresponding to the result attribute in the fields configuration list, and return to execute step S203.

[0257] Step S209, determine whether there is a next result attribute.

[0258] If so, that is, there is a next attribute result, then execute step S210.

[0259] Step S210, traverse the next result attribute, and return to execute step S206.

[0260] It should be noted that steps S201 to S210 can refer to the above steps S1 to S4, step S31, step S32, steps S41 to S46, and will not be elaborated in this embodiment.

[0261] In a possible implementation manner, the target query type configuration includes a result path configuration item for extracting a result object from the response result. Please refer to Figure 7 , extracting the result attribute from the response result in step S42 may include steps S421 and S422.

[0262] Step S421, according to the result path configuration item in the target query type configuration, extract the target result object from the response result.

[0263] Starting from the result extraction path corresponding to the result path configuration item, extract the response result, and then obtain the target result object.

[0264] Exemplarily, the response result is:

[0265]

[0266] The target result object extracted according to the result extraction path resultPath$.data in the dept query type configuration is:

[0267]

[0268] Step S422: Determine the result attributes included in the target result object.

[0269] Determining the result attributes included in the target result object can be understood as traversing the result attributes of each row in the target result object.

[0270] Exemplarily, the result attributes in the above example include id, deptCode, deptName, deptDesc, and parentDeptCode.

[0271] The result path configuration item extracts data from the response result to obtain the target result object, and then obtains the result attributes based on the target result object. Since data extraction is involved, the amount of data for determining the result attributes is reduced, thereby shortening the processing time and improving the processing efficiency.

[0272] In one embodiment, the graphql query request is as follows:

[0273]

[0274]

[0275] The target query type configuration is as follows:

[0276]

[0277] Specific parsing process:

[0278] 1) First, according to the first request query user(userId: "user1"), determine that the type name is user and the request parameter (userId: "user1").

[0279] 2) Obtain the corresponding target query type configuration according to the type name user of the first request.

[0280] 3) Replace the parameter value in the configuration item uri / api / v1 / users / {userId}, and after replacement, it becomes: / api / v1 / users / user1.

[0281] 4) Send a REST query request, that is, the second request GET / api / v1 / users / user1, and obtain the response result:

[0282]

[0283]

[0284] According to the result extraction path resultPath$.data in the user result path configuration item, the target result object is:

[0285]

[0286] And record the current type name user and the response result (which can be used for subsequent extraction of JsonPath attribute parameters of the type result), and the target result object (which can be used for subsequent extraction of result attributes).

[0287] 5) Extract the result attributes

[0288] 5.1) Traverse the result attributes under user

[0289] 5.2) Extract the attribute values of the same level and the same name from the result object as the first processed result subset, including the attribute values corresponding to id, userAccount, deptId, and roleIds

[0290] 5.3) For the result attributes dept, deptName, and roles, continue to repeat the above steps 3 to 5 according to the interface configuration items in the fields configuration list

[0291] For example, for the result attribute dept, it is necessary to continue to call the REST query request GET / api / v1 / depts / dept1, where dept1 is extracted from the response result of user according to the configuration {user[$.data.deptId]}, and the final response result of dept obtained is:

[0292]

[0293] According to the result extraction path resultPath$.data in the dept result path configuration item, the target result object is:

[0294]

[0295] Extract the attribute values of the same level and the same name from the dept result object as the second processed subset, including the attributes id, deptCode, and deptName

[0296] The extraction processes of the remaining deptName and roles are the same as that of dept, and will not be elaborated

[0297] The final graphql query request result is as follows:

[0298]

[0299] In another embodiment, when querying the user paging list, the graphql query request can be as follows:

[0300]

[0301]

[0302] The target query type configuration can be as follows:

[0303]

[0304] The present invention proposes a GraphQL query service that can be automatically implemented through configuration. The existing Http / REST service is not affected (without invading the original code). Instead, on the basis of the existing Http / REST query interface, the HTTP / REST interface is smoothly mapped to the GraphQL query service through configuration, greatly reducing the implementation cost of the GraphQL service and significantly improving the development efficiency and flexibility.

[0305] The present invention is mainly divided into two major modules: the graphql configuration module and the graphql proxy implementation module.

[0306] The graphql configuration module defines the configuration rules for mapping the HTTP / REST interface to the GraphQL query service. The configuration rules mainly consist of multiple query type configurations, and each query type configuration includes a type name, a REST service URI, a REST service Method, a result extraction path, and a fields list.

[0307] The graphql proxy implementation module is the specific implementation of the graphql query server. By parsing the configuration rules in the graphql configuration module, it automatically completes the conversion of the graphql query request to the REST service request in the form of a Web request interceptor implementation. This Web request interceptor can be applied to the application gateway and ordinary Web services. The client only needs to uniformly call the request interface exposed by this interceptor to complete the corresponding Graphql service request.

[0308] The GraphQL query service is automatically implemented through configuration, without going through the above-mentioned cumbersome access steps, and will not invade the existing HTTP / REST service. Instead, based on the existing HTTP / REST interface, it is smoothly mapped to the GraphQL query service through configuration. In this way, not only is the implementation cost of the GraphQL service greatly reduced, but the development efficiency and flexibility are also significantly improved. The client only needs to uniformly call the request interface exposed by the Web request interceptor to complete the corresponding Graphql service request. This method does not require any workload from the GraphQL server developers and is transparent to the developers, greatly improving the development efficiency of the developers and the delivery efficiency of the GraphQL service.

[0309] Based on the same inventive concept, this embodiment further provides a request processing device, as Figure 8 shown Figure 8 is a block diagram of a request processing device shown according to an exemplary embodiment. The request processing device can be applied to an electronic device. The request processing device 500 may include:

[0310] A request determination module 501, configured to determine the type name and request parameter information of a first request, where the request parameter information includes a request parameter and a request parameter value corresponding to the request parameter;

[0311] A configuration acquisition module 502, configured to acquire a target query type configuration in a preset query type configuration according to the type name, where the target query type configuration is used to convert the first request into a second request, and the endpoint architectures or communication mechanisms corresponding to the first request and the second request are different;

[0312] A request parameter replacement module 503, configured to replace the parameter value of a target configuration item in the target query type configuration whose name is the same as the request parameter with the request parameter value to obtain a second request;

[0313] A second request acquisition module 504, configured to obtain a processing result based on the second request.

[0314] Optionally, the second request acquisition module 504 includes:

[0315] A request sending unit, configured to send the second request to a database for data processing;

[0316] A result extraction unit, configured to, after receiving a response result fed back by the database for the second request, extract a result attribute from the response result and compare the result attribute with a request attribute corresponding to the request parameter in the first request;

[0317] A first subset determination unit, configured to, when the result attribute is the same as the request attribute, determine the result attribute value corresponding to the result attribute as a first processing result subset, and the processing result includes the first processing result subset.

[0318] Optionally, the target query type configuration includes a fields configuration list, and the fields configuration list is used to record at least one interface configuration item other than the target configuration item. The call interface corresponding to the target configuration item is different from the call interface corresponding to the interface configuration item. The request processing device 500 may further include:

[0319] A result attribute search module, configured to search for a result attribute in the fields configuration list;

[0320] An interface parameter replacement module, configured to, if a result attribute is found in the fields configuration list, replace the parameter value of the interface configuration item corresponding to the result attribute in the fields configuration list with the result attribute value corresponding to the result attribute, to obtain a third request.

[0321] A third request acquisition module, configured to obtain a second subset of processing results based on the third request, and the processing results further include the second subset of processing results.

[0322] Optionally, the target query type configuration includes a result path configuration item for extracting a result object from a response result, and the result extraction unit is specifically configured to:

[0323] Extract a target result object from the response result according to the result path configuration item in the target query type configuration;

[0324] Determine the result attributes included in the target result object.

[0325] Optionally, the target query type configuration includes a uniform resource identifier (URI) configuration item representing a data address and a method configuration item representing a data processing method, and the request parameter replacement module includes:

[0326] A URI configuration unit, configured to replace the parameter value of the URI configuration item in the target query type configuration with the same name as the request parameter with the request parameter value, to obtain a target URI;

[0327] A second request acquisition unit, configured to obtain a second request according to the target URI and the method configuration item.

[0328] Optionally, the determining request module 501 is specifically configured to:

[0329] In response to receiving a first request, call a Web request interceptor to intercept the first request, and determine the type name and request parameter information of the first request.

[0330] Optionally, the first request is a GraphQL service request, and the second request is a REST service request; or, the first request is a GraphQL service request, and the second request is a local call service request.

[0331] Regarding the request processing device in the above embodiments, the specific manners in which each module performs operations have been described in detail in the embodiments related to the request processing method, and will not be elaborated here.

[0332] Figure 9 It is a block diagram of an electronic device 700 shown according to an exemplary embodiment. As Figure 9As shown, the electronic device 700 may include: a processor 701 and a memory 702. The electronic device 700 may also include one or more of a multimedia component 703, an input / output (I / O) interface 704, and a communication component 705.

[0333] Among them, the processor 701 is used to control the overall operation of the electronic device 700 to complete all or part of the steps in the above request processing method. The memory 702 is used to store various types of data to support the operation of the electronic device 700. These data may include, for example, instructions for any application or method operating on the electronic device 700, as well as application-related data, such as contact data, received and sent messages, pictures, audio, video, and so on. The memory 702 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, a magnetic disk, or an optical disc. The multimedia component 703 may include a screen and an audio component. The screen may be, for example, a touch screen, and the audio component is used to output and / or input audio signals. For example, the audio component may include a microphone for receiving external audio signals. The received audio signals may be further stored in the memory 702 or sent through the communication component 705. The audio component also includes at least one speaker for outputting audio signals. The I / O interface 704 provides an interface between the processor 701 and other interface modules, and the other interface modules may be a keyboard, a mouse, buttons, etc. These buttons may be virtual buttons or physical buttons. The communication component 705 is used for wired or wireless communication between the electronic device 700 and other devices. Wireless communication, such as Wi-Fi, Bluetooth, near field communication (NFC), 2G, 3G, or 4G, or a combination of one or more of them. Accordingly, the communication component 705 may include: a Wi-Fi module, a Bluetooth module, and an NFC module.

[0334] In one exemplary embodiment, the electronic device 700 may be implemented by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components, and is used to execute the above-mentioned request processing method.

[0335] In another exemplary embodiment, a computer-readable storage medium including program instructions is further provided. When the program instructions are executed by a processor, the steps of the above-mentioned request processing method are implemented. For example, the computer-readable storage medium may be the above-mentioned memory 702 including program instructions, and the above-mentioned program instructions may be executed by the processor 701 of the electronic device 700 to complete the above-mentioned request processing method.

[0336] In another exemplary embodiment, a computer program product is further provided. The computer program product includes a computer program that can be executed by a processor. When the computer program is executed by the processor, the steps of the above-mentioned request processing method are implemented.

[0337] The preferred embodiments of the present disclosure have been described in detail above in conjunction with the accompanying drawings. However, the present disclosure is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present disclosure, various simple modifications can be made to the technical solutions of the present disclosure, and these simple modifications all fall within the protection scope of the present disclosure.

[0338] In addition, it should be noted that, among the various specific technical features described in the above specific embodiments, they can be combined in any suitable manner without conflict. To avoid unnecessary repetition, the present disclosure will not separately describe various possible combination methods.

[0339] Furthermore, any combination can be made between various different embodiments of the present disclosure as long as it does not violate the idea of the present disclosure, and it should also be regarded as the content disclosed by the present disclosure.

Claims

1. A request processing method, characterized in that Including: Determine the type name and request parameter information of the first request, where the request parameter information includes request parameters and request parameter values corresponding to the request parameters; According to the type name, obtain a target query type configuration in a preset query type configuration, where the target query type configuration is used to convert the first request into a second request, and the endpoint architecture or communication mechanism corresponding to the first request is different from that of the second request; Replace the parameter value of the target configuration item in the target query type configuration with the same name as the request parameter with the request parameter value to obtain a second request; Based on the second request, obtain a processing result.

2. The request processing method according to claim 1, characterized in that, The obtaining the processing result based on the second request includes: Send the second request to a database for data processing; After receiving the response result fed back by the database for the second request, extract result attributes from the response result, and compare the result attributes with the request attributes corresponding to the request parameters in the first request; When the result attributes are the same as the request attributes, determine the result attribute value corresponding to the result attributes as a first subset of the processing results, and the processing results include the first subset of the processing results.

3. The request processing method according to claim 2, wherein The target query type configuration includes a fields configuration list, and the fields configuration list is used to record at least one interface configuration item other than the target configuration item. The call interface corresponding to the target configuration item is different from the call interface corresponding to the interface configuration item. The request processing method further includes: Search for the result attribute in the fields configuration list; If the result attribute is found in the fields configuration list, replace the parameter value of the interface configuration item corresponding to the result attribute in the fields configuration list with the result attribute value corresponding to the result attribute to obtain a third request; Based on the third request, obtain a second subset of the processing results, and the processing results further include the second subset of the processing results.

4. The request processing method according to claim 2, wherein The target query type configuration includes a result path configuration item for extracting a result object from a response result. The extracting result attributes from the response result includes: Extract a target result object from the response result according to the result path configuration item in the target query type configuration; Determine the result attributes included in the target result object.

5. The request processing method according to claim 1, characterized in that, The target query type configuration includes a uniform resource identifier (URI) configuration item representing a data address and a method configuration item for a data processing method. The replacing the parameter value of the target configuration item in the target query type configuration with the same name as the request parameter with the request parameter value to obtain a second request includes: Replace the parameter value of the URI configuration item in the target query type configuration with the same name as the request parameter with the request parameter value to obtain a target URI; According to the target URI and the method configuration item, obtain a second request.

6. The request processing method according to claim 1, wherein The determining the type name and request parameter information of the first request includes: In response to receiving a first request, a Web request interceptor is called to intercept the first request, and the type name and request parameter information of the first request are determined.

7. The request processing method according to claim 1, characterized in that, The first request is a GraphQL service request, and the second request is a REST service request; or, the first request is the GraphQL service request, and the second request is a local call service request.

8. A request processing device, characterized in that, The request processing device includes: A request determination module, configured to determine the type name and request parameter information of the first request, where the request parameter information includes request parameters and request parameter values corresponding to the request parameters; A configuration acquisition module, configured to acquire a target query type configuration from a preset query type configuration according to the type name, where the target query type configuration is used to convert the first request into a second request, and the endpoint architectures or communication mechanisms corresponding to the first request and the second request are different; A parameter replacement module, configured to replace the parameter value of a target configuration item in the target query type configuration whose name is the same as the request parameter with the request parameter value to obtain a second request; A request acquisition module, configured to obtain a processing result based on the second request.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, the steps of the request processing method according to any one of claims 1-7 are implemented.

10. An electronic device, characterized in that, Including: A memory, on which a computer program is stored; A processor, configured to execute the computer program in the memory to implement the steps of the request processing method according to any one of claims 1-7.

Images