CN110764769A

CN110764769A - Method and device for processing user request

Info

Publication number: CN110764769A
Application number: CN201910999176.5A
Authority: CN
Inventors: 霍飞; 马荣; 李潇怡; 王磊
Original assignee: AI Speech Ltd
Current assignee: AI Speech Ltd
Priority date: 2019-10-21
Filing date: 2019-10-21
Publication date: 2020-02-07
Anticipated expiration: 2039-10-21
Also published as: CN110764769B

Abstract

The invention discloses a method and a device for processing a user request, and relates to the technical field of computers. One embodiment of the method comprises: receiving a service request of a user and determining identification data of the user; searching a corresponding format converter in a database according to the identification data; and converting the parameters in the service request through the searched format converter, and responding based on the service request after the conversion processing. The embodiment integrates the code logic of parameter conversion and encapsulation into one service for uniform processing, can flexibly process and encapsulate parameters, can deal with the change only by modifying the corresponding configuration file and without modifying program codes even if the parameter format is changed, realizes the development and deployment of common public services, is completely decoupled from the parameter format supporting the user-defined data oriented to multiple users, is not interfered with each other, and saves resources for deploying the services.

Description

Method and device for processing user request

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for processing a user request.

Background

At present, many software products are oriented to multiple clients, and the same code business logic is used for processing requests of different clients. However, different client-provided parameter information, such as parameter names, formats, etc., have client-customized request and response data templates. Since these data parameters are used in the code processing, the same code processing logic is hard to face the problem of multi-client simultaneous service.

For the above problems, there are two main solutions in the prior art: the scheme is that codes of respective services are respectively split for different clients; and the second scheme is to set a set of standard parameter formats and maintain a set of codes processed by the parameter formats by taking the formats as the reference. For the first scheme, different clients are split into codes of respective services, and parameter names in the codes and return parameter names requested by the users are changed according to the request parameter configuration of each user. That is, for each user, there is a set of request and response parameter names, and code that maintains a set of processing parameters. For the second scheme, each time the data format provided by a specific user is converted into the standard parameter format for uniform processing, the returned parameters also need to be rewritten into uniform conversion processing codes each time so as to obtain the output format required by the client.

In the implementation process of the two schemes, the main problems are as follows: it is inevitable to add parameter format conversion code logic to the business logic of each service. This parameter format conversion and encapsulated code is scattered among each service, reducing both development efficiency and code maintainability. The code logic of parameter conversion dispersed in each service has strong coupling with business logic, and cannot concentrate parameter conversion and encapsulation on the same service processing, thus violating the basic principle of single responsibility and aggregation multiplexing of program design. When the user's demand changes, the code is inevitably modified, and it is difficult to cope with such temporary changes.

Disclosure of Invention

In view of this, embodiments of the present invention provide a method and an apparatus for processing a user request, in which a parameter format conversion and an encapsulated code are extracted into a configuration file, and both logic of the parameter conversion and the encapsulated code are integrated in one service and processed uniformly, so that parameters can be flexibly processed and encapsulated, and even if a parameter format changes, only a corresponding configuration file needs to be modified, and a program code does not need to be modified to cope with the change.

To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method of processing a user request, including: receiving a service request of a user and determining identification data of the user; searching a corresponding format converter in a database according to the identification data; and converting the parameters in the service request through the searched format converter, and responding based on the service request after the conversion processing.

Optionally, before receiving a service request of a user and determining the identification data of the user, the method further includes: configuring a format converter of a user according to the request parameter requirement of the user; wherein, the format converter is a configuration file of the SpEL; storing the format converter of the user to the database and generating identification data of the user.

Optionally, the step of performing conversion processing on the parameter in the service request by using the searched format converter includes: initializing the SpEL context of the searched format converter according to the parameters of the service request; judging whether a request uniform resource locator Url exists or not; if the SpEL does not exist, performing format conversion on the parameters in the service request by the SpEL and refreshing the SpEL context; otherwise, filling the placeholder, and determining the order of format conversion by using the SpEL according to the object request type of the searched format converter; and performing format conversion of the parameters based on the sequence.

Optionally, after performing conversion processing on the parameter in the service request by the searched format converter and responding based on the service request after the conversion processing, the method further includes: and according to the searched format converter, carrying out data format packaging on the response of the service request.

Optionally, the database is a Mongo database.

According to still another aspect of the embodiments of the present invention, there is provided an apparatus for processing a user request, including: the receiving module is used for receiving a service request of a user and determining the identification data of the user; the searching module is used for searching a corresponding format converter in a database according to the identification data; and the conversion module is used for converting the parameters in the service request through the searched format converter and responding based on the service request after the conversion processing.

Optionally, the system further comprises a configuration module, configured to configure a format converter of the user according to a request parameter requirement of the user; wherein, the format converter is a configuration file of the SpEL; storing the format converter of the user to the database and generating identification data of the user.

Optionally, the conversion module is further configured to initialize an SpEL context of the format converter according to the parameter of the service request; judging whether a request uniform resource locator Url exists or not; if the SpEL does not exist, performing format conversion on the parameters in the service request by the SpEL and refreshing the SpEL context; otherwise, filling the placeholder, and determining the sequence of format conversion by using the SpEL according to the type of the format converter object request; and performing format conversion of the parameters based on the sequence.

Optionally, the conversion module is further configured to perform data format encapsulation on the response to the service request according to a format converter.

Optionally, the database is a Mongo database.

According to another aspect of the embodiments of the present invention, there is provided a system for processing a user request, including:

one or more processors;

a storage device for storing one or more programs,

when the one or more programs are executed by the one or more processors, the one or more processors implement the method for processing the user request provided by the present invention.

According to a further aspect of the embodiments of the present invention, there is provided a computer-readable medium on which a computer program is stored, the program, when executed by a processor, implementing the method for processing a user request provided by the present invention.

One embodiment of the above invention has the following advantages or benefits: aiming at different request parameters of different users and different required response formats, a corresponding format converter is configured for each different client requirement and is used for converting corresponding parameter data. And extracting the code subjected to parameter format conversion and encapsulation into a configuration file. The code logic of parameter conversion and encapsulation is integrated in one service for uniform processing, and the parameters can be flexibly processed and encapsulated, even if the parameter format is changed, only the corresponding configuration file needs to be modified, and the program code does not need to be modified to deal with the change, so that the development efficiency and the code maintainability are improved.

Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.

Drawings

The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:

FIG. 1 is a schematic diagram of the main flow of a method of processing a user request according to an embodiment of the invention;

FIG. 2 is a schematic diagram of a method of processing a user request according to an embodiment of the invention;

FIG. 3 is a schematic diagram of a method of processing a user request according to an embodiment of the invention;

FIG. 4 is a schematic diagram of a data format-by-data format processing flow according to an embodiment of the invention;

FIG. 5 is a schematic diagram of the main modules of an apparatus for processing a user request according to an embodiment of the present invention;

FIG. 6 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;

fig. 7 is a schematic block diagram of a computer system suitable for use in implementing a terminal device or server of an embodiment of the invention.

Detailed Description

Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Fig. 1 is a schematic diagram of a main flow of a method of processing a user request according to an embodiment of the present invention. As shown in fig. 1, the method for processing a user request according to an embodiment of the present invention mainly includes:

step S101: a service request of a user is received and identification data of the user is determined. In the embodiment of the invention, for different clients, when the configuration file of the format converter is stored, a unique identifier is correspondingly generated, namely the identification data of the user.

Step S102: and searching the corresponding format converter in the database according to the identification data.

Step S103: and converting the parameters in the service request through the searched format converter, and responding based on the converted service request.

According to the technical scheme of the embodiment of the invention, aiming at different request parameters and different required response formats of different users, a corresponding format converter is configured for each different client requirement and is used for converting corresponding parameter data. And extracting the code subjected to parameter format conversion and encapsulation into a configuration file. The code logic of parameter conversion and encapsulation is integrated in one service for uniform processing, and the parameters can be flexibly processed and encapsulated, even if the parameter format is changed, only the corresponding configuration file needs to be modified, and the program code does not need to be modified to deal with the change, so that the development efficiency and the code maintainability are improved.

For the problem that the same code processing logic is difficult to face to the simultaneous service of multiple clients, two schemes mainly exist in the prior art, and specific analysis is performed below. The splitting of the client into the respective services means that the same business processing logic is modified according to the requirements of each user. Even if the service logic is the same, the client parameter configuration is different, and the parameter-related service logic in the code needs to be configured one by one and modified. All relevant parameters in the code and even the data structures involved need to be altered. The modified code is also valid only for a single client, which is equivalent to deploying dedicated services every time a new client comes. Each service is independent of the other and serves only a single customer. So that the code, which makes the business logic the same, is distributed in each service.

Another unified data format-based process is to manually convert a specific user-specific parameter format into a parameter format already defined in the code logic in a section of code processing before invoking the unified code logic process. It is also necessary to manually configure the data format desired by a particular client after obtaining a response to the business process. Similar to splitting into respective services, the processing method needs to add a code for converting the parameter format or encapsulating the parameter format into the service, and only extracts the same parameter into a unified code for processing compared with the split service. And if the user-defined parameter format is not consistent with the parameter format in the current code logic, the user is determined as the specific user.

As can be seen from the above, splitting into respective services for clients results in repeated development, and many names of parameters run through the whole code logic, and the code modification range is uncertain. This undoubtedly brings a high cost, inefficient repetitive workload to the code development work. Moreover, the service of each client needs to be deployed independently, and the same service occupies multiple server resources, which causes waste of deployment resources. And based on uniform data format processing, the formats of input parameters and output parameters need to be configured separately for each client before the service is called, so that the service deployed only once can be used for different client request services. Although compared with the method that the code is completely split and configured each time, most of service deployment resources are saved, and the code modification range is determined, the code development work cannot be avoided when a new user requests the code.

Currently, the industry essentially adopts both of these strategies for providing the same service to multiple customers. For the case of a small amount of customers, the requirement that the service deployment resources are sufficient and the variable range in the code is easy to be clearly located is generally in a mode of directly modifying the code. The strategy ensures that the services of different clients do not interfere with each other, and if the service of one client is in problem or the service is required to be developed again in a subsequent customization mode, the strategy can more conveniently locate the problem without considering the influence of the modified code on the services of other clients. However, most public services are directed to a relatively large number of customers, and other peers use a uniformly formatted data format to satisfy the service to new customers. The common service used by all the clients is the same, and data format processing is performed before and after service calling for each client. Before calling, converting a data structure provided by a user into a format required by a service; after the service, the result of the service is packaged according to the format desired by the user, and then the result is transferred to the user.

When the service is just developed, the service is likely to be developed according to the requirements of a specific client, and the development is directly completed according to the requirements of the specific client. When the number of clients to which the service is oriented increases, since the expandability is not considered in the previous development, in order not to affect the client service already deployed, the common thinking is to develop similar services for new clients again by referring to the previous service logic.

Fig. 2 is a schematic diagram of a method of processing a user request according to an embodiment of the present invention. As shown in fig. 2, the method for processing a user request according to an embodiment of the present invention includes:

step S201: configuring a format converter of a user according to the request parameter requirement of the user; wherein, the format converter is a configuration file of the SpEL. The spring Expression language is a powerful Expression language supporting query and operation of runtime object navigation graph functions, and can be operated by constructing expressions, accessing attribute values of objects, or calling methods of objects during runtime.

For parameters with the same meaning, the names used by different customers in the parameters of a request or a response may be different, such as a product number parameter, a customer uses a parameter name: productId, B customer use parameter name: pid, C customer usage parameter name: chanpinld. Such differentiation of parameter names occurs not only in the parameters of the request but also in the parameters of the response. Therefore, for different request parameters of different clients and different required response formats, the request parameters of the embodiment of the invention use the SpEL statements to store configuration files in the database, and a data format converter is configured for converting the corresponding parameter data for each different client requirement.

Preferably, the database is a Mongo database. MongoDB is a product between relational databases and non-relational databases, and among the non-relational databases, the MongoDB has the most abundant functions and is most similar to the relational databases. And the Mongo database supports very powerful query language, the syntax of the Mongo database is similar to the object-oriented query language, most functions of single-table query of the similar relational database can be almost realized, and the index establishment of the data is supported.

Step S202: the format converter of the user is stored to a database and identification data of the user is generated. Different clients, when storing the configuration file, generate a unique identifier.

Step S203: a service request of a user is received and identification data of the user is determined.

Step S204: and searching the corresponding format converter in the database according to the identification data. Every time a user request reaches public service, a format conversion definition which is configured in advance and corresponds to the user is searched in the Mongo database according to the unique identification of the user. The parameters are preprocessed according to the SpEL expression of the format converter, and the SpEL expression can also define the output parameter format used by the user. Meanwhile, format conversion also supports sending a request for parameter conversion, and data format encapsulation is carried out after the request is finished by using parameter configuration.

In particular, the SpEL context of the format converter is initialized according to the parameters of the service request. Judging whether a request uniform resource locator Url exists or not; if the SpEL does not exist, performing format conversion on the parameters in the service request by the SpEL and refreshing the SpEL context; otherwise, filling the placeholder, and determining the sequence of format conversion by using the SpEL according to the type of the format converter object request; format conversion of the parameters is performed on an order basis.

Step S205: and converting the parameters in the service request through the searched format converter, and responding based on the converted service request.

According to the technical scheme of the embodiment of the invention, the format conversion and encapsulation of the data based on the SpEL service are very suitable for most of the service services developed based on the Spring framework. For new customer requirements, only the statement configuration in the database needs to be operated, and secondary development in codes is not needed. The development and deployment of the common public service are realized, and the complete decoupling of the multi-user-oriented user-defined data parameter format is supported without mutual interference. Resources for deploying the service are saved, and the public service only needs to be deployed once. And, the location of service problems is facilitated. If the same service problem occurs to multiple users at the same time, positioning the specific position of the service code; if the service of a single client is not available or a problem occurs, the converter configuration of the SpEL expression corresponding to the Mongo database is checked.

FIG. 3 is a schematic diagram of a method of processing a user request according to an embodiment of the invention; fig. 4 is a schematic diagram of a data format-by-data format processing flow according to an embodiment of the invention.

As shown in fig. 3, when a user's custom request enters a public service in JSON format, a request id or service id is simultaneously introduced as a unique identifier. The service inquires whether a data format converter corresponding to the request or the service in advance exists in the Mongo database according to the unique identifier, and the query is called as cleaner. Each Cleaner is a corresponding SpEL statement stored in a configuration file in a Mongo database and used for converting the data format of the corresponding parameter.

If there is a corresponding cleaner, the context of the SpEL is initialized according to the user's input JSON parameter. The SpEL context is then refreshed based on whether the request Url (uniform resource locator) is configured. If there is no request Url, the SpEL expression in cleaner is executed for preprocessing, and the SpEL context is refreshed. The preprocessing is to prepare for parameter conversion, such as a user requesting that the parameter be the text "123", and the preprocessing is to convert to the number 123, and then to perform an operation based on the number. If there is a request Url, the placeholder is first filled, and then the cleaner object request type is determined, thereby deciding whether to pre-process using the SpEL expression before or after the request is called, and refreshing the SpEL context. Preprocessing before calling the request, namely preprocessing parameters of the request; the preprocessing is performed after the request, namely, the preprocessing is performed on the parameters of the response after the request.

Then, entering a data packaging stage, and replacing the placeholder according to the context to obtain JSON data of the semi-finished product; and then determines whether clean syntax processing is required. If not, the results are packaged according to the customer requirement format. If necessary, parameter format writing is separately performed according to syntax.

As shown in fig. 4, the flow of data format-by-data format processing or encapsulation includes: firstly, checking the syntax of the SpEL in cleaner, and if the processing logic is For each (repeating an embedded statement group For each element in an array or an object set), reestablishing the SpEL context according to a processing object provided by a user; then, acquiring a variable array of the loop input parameter object, executing each preprocessor one by one and initializing the context of the SpEL; and finally, circularly outputting keys in the array, obtaining an output result corresponding to each parameter according to SpEL processing, and packaging the JSON data output path after Cleaner processing according to path configuration.

Fig. 5 is a schematic diagram of main blocks of an apparatus for processing a user request according to an embodiment of the present invention. The main modules of the apparatus for processing a user request according to the embodiment of the present invention include a receiving module 501, a searching module 502, and a converting module 503.

A conversion module 501, configured to receive a service request of a user and determine identification data of the user.

The searching module 502 is configured to search the corresponding format converter in the database according to the identification data.

The conversion module 503 is configured to perform conversion processing on the parameter in the service request through the searched format converter, and perform response based on the service request after the conversion processing.

The device for processing the user request of the embodiment of the invention also comprises a configuration module, a format converter and a processing module, wherein the configuration module is used for configuring the format converter of the user according to the request parameter requirement of the user; the format converter is a configuration file of the SpEL; the format converter of the user is stored to a database and identification data of the user is generated. The conversion module is further used for initializing the SpEL context of the format converter according to the parameters of the service request; judging whether a request uniform resource locator Url exists or not; if the SpEL does not exist, performing format conversion on the parameters in the service request by the SpEL and refreshing the SpEL context; otherwise, filling the placeholder, and determining the sequence of format conversion by using the SpEL according to the type of the format converter object request; format conversion of the parameters is performed on an order basis.

The conversion module is further configured to perform data format encapsulation on the response to the service request according to the format converter. And/or the database is a Mongo database.

According to the technical scheme of the embodiment of the invention, aiming at different request parameters and different required response formats of different users, a corresponding format converter is configured for each different client requirement and is used for converting corresponding parameter data. And extracting the code subjected to parameter format conversion and encapsulation into a configuration file. The code logic of parameter conversion and encapsulation are all integrated in one service for uniform processing, and can flexibly process and encapsulate parameters. And for new customer requirements, only the statement configuration in the database needs to be operated, and secondary development in codes is not needed. The development and deployment of the common public service are realized, and the complete decoupling of the multi-user-oriented user-defined data parameter format is supported without mutual interference. Resources for deploying the service are saved, and the public service only needs to be deployed once.

Fig. 6 illustrates an exemplary system architecture 600 of a method of processing a user request or an apparatus for processing a user request to which embodiments of the present invention may be applied.

As shown in fig. 6, the system architecture 600 may include

terminal devices

601, 602, 603, a network 604, and a server 605. The network 604 serves to provide a medium for communication links between the

terminal devices

601, 602, 603 and the server 605. Network 604 may include various types of connections, such as wire, wireless communication links, or fiber optic cables, to name a few.

A user may use the

terminal devices

601, 602, 603 to interact with the server 605 via the network 604 to receive or send messages or the like. The

terminal devices

601, 602, 603 may have installed thereon various communication client applications, such as shopping applications, web browser applications, search applications, instant messaging tools, mailbox clients, social platform software, etc. (by way of example only).

The

terminal devices

601, 602, 603 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.

The server 605 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the

terminal devices

601, 602, 603. The background management server can analyze and process the received data such as the product information inquiry request and feed back the processing result to the terminal equipment.

It should be noted that the method for processing the user request provided by the embodiment of the present invention is generally executed by the server 605, and accordingly, the apparatus for processing the user request is generally disposed in the server 605.

It should be understood that the number of terminal devices, networks, and servers in fig. 6 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.

Referring now to FIG. 7, shown is a block diagram of a computer system 700 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 7 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.

As shown in fig. 7, the computer system 700 includes a Central Processing Unit (CPU)701, which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)702 or a program loaded from a storage section 708 into a Random Access Memory (RAM) 703. In the RAM 703, various programs and data necessary for the operation of the system 700 are also stored. The CPU 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input/output (I/O) interface 705 is also connected to bus 704.

The following components are connected to the I/O interface 705: an input portion 706 including a keyboard, a mouse, and the like; an output section 707 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a network interface card such as a LAN card, a modem, or the like. The communication section 709 performs communication processing via a network such as the internet. A drive 710 is also connected to the I/O interface 705 as needed. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 710 as necessary, so that a computer program read out therefrom is mounted into the storage section 708 as necessary.

In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication section 709, and/or installed from the removable medium 711. The computer program performs the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 701.

It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a receiving module, a lookup module, and a translation module. Where the names of these modules do not in some cases constitute a limitation of the module itself, for example, a receiving module may also be described as a "module that receives a service request of a user and determines identification data of said user".

As another aspect, the present invention also provides a computer-readable medium that may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise: receiving a service request of a user and determining identification data of the user; searching a corresponding format converter in a database according to the identification data; and converting the parameters in the service request through the searched format converter, and responding based on the converted service request.

The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A method of processing a user request, comprising:

receiving a service request of a user and determining identification data of the user;

searching a corresponding format converter in a database according to the identification data;

and converting the parameters in the service request through the searched format converter, and responding based on the converted service request.

2. The method of claim 1, further comprising, prior to receiving a service request from a user and determining identification data for the user:

configuring a format converter of a user according to the request parameter requirement of the user; wherein, the format converter is a configuration file of the SpEL;

storing the format converter of the user to the database and generating identification data of the user.

3. The method of claim 2, wherein the step of converting the parameters in the service request by the looked-up format converter comprises:

initializing the SpEL context of the searched format converter according to the parameters of the service request;

judging whether a request uniform resource locator Url exists or not;

if the SpEL does not exist, performing format conversion on the parameters in the service request by the SpEL and refreshing the SpEL context;

otherwise, filling the placeholder, and determining the order of format conversion by using the SpEL according to the object request type of the searched format converter; and performing format conversion of the parameters based on the sequence.

4. The method according to any of claims 1-3, further comprising, after performing conversion processing on the parameters in the service request by the lookup format converter and responding based on the converted service request:

and according to the searched format converter, carrying out data format packaging on the response of the service request.

5. An apparatus for processing a user request, comprising:

the receiving module is used for receiving a service request of a user and determining the identification data of the user;

the searching module is used for searching a corresponding format converter in a database according to the identification data;

and the conversion module is used for converting the parameters in the service request through the searched format converter and responding based on the service request after the conversion processing.

6. The apparatus of claim 5, further comprising a configuration module for configuring a format converter of a user according to a request parameter requirement of the user; wherein, the format converter is a configuration file of the SpEL; storing the format converter of the user to the database and generating identification data of the user.

7. The apparatus of claim 6, wherein the conversion module is further configured to initialize a SpEL context of the looked-up format converter according to the parameters of the service request; judging whether a request uniform resource locator Url exists or not; if the SpEL does not exist, performing format conversion on the parameters in the service request by the SpEL and refreshing the SpEL context; otherwise, filling the placeholder, and determining the order of format conversion by using the SpEL according to the object request type of the searched format converter; and performing format conversion of the parameters based on the sequence.

8. The apparatus of any of claims 5-7, wherein the conversion module is further configured to perform data format encapsulation on the response to the service request according to the format converter of the lookup.

9. A system for processing a user request, comprising:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-4.

10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-4.