A non-invasive data interaction method and device in the scenario of front-end and back-end separation

Abstract

The present invention relates to the technical field of data interaction methods, and particularly relates to a non-intrusive data interaction method and device in a scenario of front-end and back-end separation. By respectively configuring a global request interceptor H at the front end Req and a global response interceptor H Resp , and configuring a global request interceptor H at the back end Back and verification metadata, the general data verification logic at the back end and the data interaction logic between the front end and the back end are centralized in one place, which not only eliminates the code redundancy of these logics, but also reduces the intrusion of these logics into the business logics contained in each specific business module (page), thereby improving the scalability of the system.

Description

Technical Field

[0001] The present invention relates to the technical field of data interaction methods, and in particular, to a non-invasive data interaction method and device in a scenario of front-end and back-end separation. Background Art

[0002] Front-end and back-end separation is a development method adopted by many current complex software systems. To ensure system security, both the front-end and the back-end need to perform general verification on various data submitted by users (such as whether it is empty, whether the format is legal, whether the length / range is legal, etc.). However, the currently commonly used verification logic implementation methods have the following deficiencies:

[0003] 1. The same type of verification logic (only the prompt text for informing users is different) appears in large quantities in each business module (page) of the front-end and the back-end, resulting in a high code redundancy.

[0004] 2. The code for implementing the general verification logic invades the code for implementing the specific interaction logic (for the front-end) and the business logic (for the back-end), seriously reducing the code comprehensibility and system scalability. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to propose a non-invasive data interaction method and device in a scenario of front-end and back-end separation to solve the above technical problems.

[0006] Based on the above purpose, the present invention provides a non-invasive data interaction method in a scenario of front-end and back-end separation, including:

[0007] Setting front-end general verification logic in the front-end business module and configuring a global request interceptor H in the front-end Req , where H Req Describes all requests that need to be centrally processed in the front-end through a regular expression RE Front ;

[0008] When the front-end obtains a request P, if the request P passes the verification in the front-end general verification logic, it is determined whether the request P matches RE Front . If not, the request P is sent to the back-end; if it matches, after the front-end executes the operation logic corresponding to the request parameters included in the request P and / or triggers the corresponding UI rendering logic, the request P is sent to the back-end;

[0009] Configuring a global request interceptor H in the back-end Back , where H Back Describes all requests that need to be centrally processed in the back-end through a regular expression RE BackDescribe all requests that need to be centrally processed at the backend; configure several backend general verification logics that are all adapted to the type based on the type of request parameters, and configure 0 to N backend general verification logics for each formal parameter in the form of metadata before each formal parameter in the backend business module, where N is a positive integer;

[0010] The backend obtains the request P sent by the frontend; if the request P matches RE Back , obtain the formal parameter Arg included in the request P and the metadata Meta of the backend general verification logic corresponding to the formal parameter Arg. If all the formal parameters Arg satisfy the backend general verification logic with the corresponding Meta as the constraint condition, and all the formal parameters Arg satisfy the self-verification logic of the backend business module, then the backend executes the operation logic corresponding to the request parameters included in the request P and constructs a data structure R with succ = TRUE, otherwise, constructs a data structure R with succ = FALSE and msg as the prompt copy corresponding to the self-verification logic of this backend business module; if the request P does not match RE Back and all the formal parameters Arg satisfy the self-verification logic of the backend business module, then the backend executes the operation logic corresponding to the request parameters included in the request P and constructs a data structure R with succ = TRUE, otherwise, constructs a data structure R with succ = FALSE and msg as the prompt copy corresponding to the self-verification logic of this backend business module;

[0011] The backend serializes the data structure R and sends the serialized data structure R to the frontend;

[0012] Configure a global response interceptor H at the frontend Resp , where the H Resp receives the serialized data structure R sent by the backend. If the succ of the data structure R is FALSE, then a prompt copy with the msg of the data structure R as the content is popped up to end this interaction; if succ is TRUE, then the attach in the data structure R is passed to the request callback method of the corresponding frontend business module. In the request callback method, obtain the attach information returned by the H Resp and update the corresponding UI elements or execute the corresponding actions in the frontend page according to the frontend business module involved in this request P to end this interaction.

[0013] As an optional implementation manner, it further includes: writing a prompt copy M when the verification fails in the frontend business module. If the request P fails the verification in the frontend general verification logic, then the prompt copy M is returned.

[0014] As an optional implementation manner, it further includes: the H RespAfter receiving the serialized data structure R sent by the backend, the triggered UI rendering logic is terminated.

[0015] As an alternative implementation, the data structure R includes:

[0016] A boolean succ, used to mark whether the backend service module of the request has been executed successfully;

[0017] A string msg, used to store the copywriting that needs to be presented to the user when the backend service module finishes execution;

[0018] Additional data attach, used to store the data required to update the corresponding UI elements in the front-end page after the backend service module has been successfully executed. attach is designed as the root class of the programming language or the "key-value pair" type.

[0019] As an alternative implementation, the front-end executes the operation logic corresponding to the request parameters included in request P, including: parameter type conversion and / or removing the leading and trailing whitespace characters of string-type parameters and / or escaping special characters included in string-type parameters and / or adding an authentication Token parameter.

[0020] As an alternative implementation, the front-end triggers the corresponding UI rendering logic, including: displaying an indeterminate progress bar and / or popping up a mask layer with a waiting animation and / or prohibiting the user from repeating operations.

[0021] As an alternative implementation, based on the type of the request parameters, a number of backend general verification logics adapted to the type are configured, including: determining whether the request parameters are empty; and / or,

[0022] Determining whether the lengths of string-type parameters and array-type parameters are legal; and / or,

[0023] Determining whether numeric parameters are within a legal value range; and / or,

[0024] Determining whether date / time-type parameters are before or after the current date / time.

[0025] Corresponding to the interaction method, an embodiment of the present invention further provides a non-intrusive data interaction device in a front-backend separation scenario, including:

[0026] A front-end configuration module, used to set front-end general verification logic in the front-end service module and configure a global request interceptor H in the front-end Req , where H Req Describes all requests that need to be centrally processed in the front-end through a regular expression RE Front ;

[0027] Front-end acquisition module, used to enable the front-end to obtain request P. If request P passes the verification in the front-end general verification logic, then it is determined whether request P matches RE Front ; if not, send request P to the back-end; if it matches, after the front-end executes the operation logic corresponding to the request parameters included in request P and / or triggers the corresponding UI rendering logic, send request P to the back-end;

[0028] Back-end configuration module, used to configure the global request interceptor H at the back-end Back , where H Back describes all requests that need to be centrally processed at the back-end through the regular expression RE Back ; based on the type of request parameters, configure several back-end general verification logics that are all adapted to the type, and configure 0 to N back-end general verification logics for each formal parameter in the form of metadata before each formal parameter of the back-end business module, where N is a positive integer;

[0029] Back-end acquisition module, used to enable the back-end to obtain request P sent by the front-end; if request P matches RE Back , obtain the formal parameter Arg included in request P and the metadata Meta of the back-end general verification logic corresponding to the formal parameter Arg. If all formal parameters Arg satisfy the back-end general verification logic with the corresponding Meta as the constraint condition, and all formal parameters Arg satisfy the self-verification logic of the back-end business module, then the back-end executes the operation logic corresponding to the request parameters included in request P and constructs a data structure R with succ = TRUE, otherwise, constructs a data structure R with succ = FALSE and msg as the prompt text corresponding to the self-verification logic of the back-end business module; if request P does not match RE Back , and all formal parameters Arg satisfy the self-verification logic of the back-end business module, then the back-end executes the operation logic corresponding to the request parameters included in request P and constructs a data structure R with succ = TRUE, otherwise, constructs a data structure R with succ = FALSE and msg as the prompt text corresponding to the self-verification logic of the back-end business module;

[0030] Serialization module, used to enable the back-end to serialize the data structure R and send the serialized data structure R to the front-end;

[0031] Response and interaction module, used to configure the global response interceptor H at the front-end Resp , the H RespReceive the serialized data structure R sent by the backend. If the succ of the data structure R is FALSE, pop up a prompt text with the content of the msg of the data structure R to end the current interaction; if succ is TRUE, pass the attach in the data structure R to the request callback method of the corresponding front-end business module, and obtain H in the request callback method Resp The returned attach information, and update the corresponding UI elements or perform corresponding actions in the front-end page according to the front-end business module involved in the request P to end the current interaction.

[0032] Advantages of the present invention: The embodiments of the present invention provide a non-intrusive data interaction method and device in a front-back end separation scenario. By respectively configuring a global request interceptor H in the front end Req and a global response interceptor H Resp and configuring a global request interceptor H in the backend Back and verification metadata, the general data verification logic of the backend and the data interaction logic between the front and back ends are concentrated in one place, which not only eliminates the code redundancy of these logics, but also reduces the intrusion of these logics into the business logics contained in each specific business module (page), thereby improving the scalability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only those of the present invention. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without creative efforts.

[0034] Figure 1 It is a schematic diagram of the interaction method of the embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0035] In order to make the objectives, technical solutions, and advantages of the present invention clearer, the following further details the present invention with reference to specific embodiments.

[0036] To achieve the above objectives, the embodiments of the present invention provide a non-intrusive data interaction method in a front-back end separation scenario. This method can be applied to terminals, servers, or server clusters, etc., without specific limitations. The following details the non-intrusive data interaction method provided by the embodiments of the present invention.

[0037] The embodiments of the present invention provide a non-intrusive data interaction method in a front-back end separation scenario, including:

[0038] S100. Set the front - end general verification logic in the front - end business module, and configure the global request interceptor H in the front - end Req , where H Req describes all requests that need to be centrally processed in the front - end through the regular expression RE Front ;

[0039] S200. The front - end obtains the request P. If the request P passes the verification in the front - end general verification logic, then determine whether the request P matches RE Front . If it does not match, send the request P to the back - end; if it matches, after the front - end executes the operation logic corresponding to the request parameters included in the request P and / or triggers the corresponding UI rendering logic, send the request P to the back - end;

[0040] S300. Configure the global request interceptor H in the back - end Back , where H Back describes all requests that need to be centrally processed in the back - end through the regular expression RE Back ; configure several back - end general verification logics that are all adapted to the type based on the type of the request parameters, and configure 0 - N back - end general verification logics for each formal parameter in the form of metadata before each formal parameter in the back - end business module, where N is a positive integer;

[0041] S400. The back - end obtains the request P sent by the front - end; if the request P matches RE Back , obtain the formal parameter Arg included in the request P and the metadata Meta of the back - end general verification logic corresponding to the formal parameter Arg. If all the formal parameters Arg satisfy the back - end general verification logic with the corresponding Meta as the constraint condition, and all the formal parameters Arg satisfy the self - verification logic of the back - end business module, then the back - end executes the operation logic corresponding to the request parameters included in the request P and constructs the data structure R with succ = TRUE, otherwise, constructs the data structure R with succ = FALSE and msg as the prompt text corresponding to the self - verification logic of this back - end business module; if the request P does not match RE Back , and all the formal parameters Arg satisfy the self - verification logic of the back - end business module, then the back - end executes the operation logic corresponding to the request parameters included in the request P and constructs the data structure R with succ = TRUE, otherwise, constructs the data structure R with succ = FALSE and msg as the prompt text corresponding to the self - verification logic of this back - end business module;

[0042] S500. The back - end serializes the data structure R and sends the serialized data structure R to the front - end;

[0043] S600. Configure the global response interceptor H in the front - end Resp , the H RespReceive the serialized data structure R sent by the backend. If the succ of the data structure R is FALSE, pop up a prompt text with the content of the msg of the data structure R to end the current interaction; if succ is TRUE, pass the attach in the data structure R to the request callback method of the corresponding front-end business module, and obtain H in the request callback method Resp The returned attach information, and according to the front-end business module involved in the request P, update the corresponding UI elements in the front-end page or perform corresponding actions to end the current interaction.

[0044] An embodiment of the present invention provides a non-intrusive data interaction method in a scenario of front-end and back-end separation. By respectively configuring a global request interceptor H in the front-end Req and a global response interceptor H Resp and configuring a global request interceptor H in the backend Back and verification metadata, the general data verification logic of the backend and the data interaction logic between the front-end and the back-end are centralized in one place, which not only eliminates the code redundancy of these logics, but also reduces the intrusion of these logics into the business logics contained in each specific business module (page), thereby improving the scalability of the system.

[0045] As an optional implementation manner, the non-intrusive data interaction method further includes writing a prompt text M when verification fails in the front-end business module. If the request P fails the verification in the front-end general verification logic, return the prompt text M.

[0046] As an optional implementation manner, the non-intrusive data interaction method further includes that after the H Resp receives the serialized data structure R sent by the backend, it ends the triggered UI rendering logic.

[0047] As an optional implementation manner, the data structure R includes:

[0048] A boolean succ, used to mark whether the backend business module of the request is executed successfully;

[0049] A string msg, used to store the text that needs to be presented to the user when the backend business module finishes execution;

[0050] Additional data attach, used to store the data required to update the corresponding UI elements in the front-end page after the backend business module successfully finishes execution. attach is designed as the root class of the programming language or the "key-value pair" type.

[0051] As an alternative implementation, the operation logic corresponding to the request parameters included in the front-end execution request P includes: parameter type conversion and / or removing leading and trailing whitespace characters of string-type parameters and / or escaping special characters included in string-type parameters and / or adding an authentication Token parameter.

[0052] As an alternative implementation, the front-end triggers the corresponding UI rendering logic, including: displaying an indeterminate progress bar and / or popping up a mask layer with a waiting animation and / or prohibiting the user from repeating operations.

[0053] As an alternative implementation, based on the type of the request parameters, a number of backend general verification logics adapted to the type are configured, including: determining whether the request parameters are empty; and / or,

[0054] determining whether the lengths of string-type parameters and array-type parameters are legal; and / or,

[0055] determining whether numeric parameters are within a legal value range; and / or,

[0056] determining whether date / time-type parameters are before or after the current date / time.

[0057] Corresponding to the non-intrusive data interaction method, the present invention also provides a non-intrusive data interaction device in a front-end and back-end separated scenario, including:

[0058] A front-end configuration module for setting front-end general verification logic in the front-end business module and configuring a global request interceptor H in the front-end Req , where H Req describes all requests that need to be centrally processed in the front-end through a regular expression RE Front ;

[0059] A front-end acquisition module for enabling the front-end to acquire a request P. If the request P passes the verification in the front-end general verification logic, it is determined whether the request P matches RE Front . If not, the request P is sent to the back-end; if it matches, after the front-end executes the operation logic corresponding to the request parameters included in the request P and / or triggers the corresponding UI rendering logic, the request P is sent to the back-end;

[0060] A back-end configuration module for configuring a global request interceptor H in the back-end Back , where H Back describes all requests that need to be centrally processed in the front-end through a regular expression RE BackDescribe all requests that need to be centrally processed at the backend; based on the types of request parameters, configure several backend general verification logics that are all adapted to the types, and configure 0 to N backend general verification logics for each formal parameter in the form of metadata before each formal parameter in the backend business module, where N is a positive integer;

[0061] Backend acquisition module, used to enable the backend to acquire the request P sent by the frontend; if the request P matches RE Back Match, acquire the formal parameter Arg included in the request P and the metadata Meta of the backend general verification logic corresponding to the formal parameter Arg. If all formal parameters Arg satisfy the backend general verification logic with the corresponding Meta as the constraint condition, and all formal parameters Arg satisfy the self-verification logic of the backend business module, then the backend executes the operation logic corresponding to the request parameters included in the request P, and constructs a data structure R with succ = TRUE, otherwise, constructs a data structure R with succ = FALSE and msg as the prompt copy corresponding to the self-verification logic of this backend business module; if the request P does not match RE Back Do not match, and all formal parameters Arg satisfy the self-verification logic of the backend business module, then the backend executes the operation logic corresponding to the request parameters included in the request P, and constructs a data structure R with succ = TRUE, otherwise, constructs a data structure R with succ = FALSE and msg as the prompt copy corresponding to the self-verification logic of this backend business module;

[0062] Serialization module, used to enable the backend to serialize the data structure R and send the serialized data structure R to the frontend;

[0063] Response and interaction module, used to configure a global response interceptor H at the frontend Resp The H Resp Receives the serialized data structure R sent by the backend. If the succ of the data structure R is FALSE, then a prompt copy with the msg of the data structure R as the content is popped up to end this interaction; if succ is TRUE, then the attach in the data structure R is passed to the request callback method of the corresponding frontend business module, and the attach information returned by the H Resp is obtained in the request callback method, and according to the frontend business module involved in the request P, the corresponding UI elements in the frontend page are updated or the corresponding actions are executed to end this interaction.

[0064] Embodiment

[0065] To further facilitate the understanding of this solution, specific embodiments are now combined with Figure 1 for illustration.

[0066] Step 1: Design a unified data structure ServiceResult (abbreviated as R) for each backend business module, which is the data type returned by the backend after each front-end business request is sent to the backend. R contains three parts of information: ① a boolean succ, used to mark whether the backend business module of the request is executed successfully; ② a string msg, used to store the copywriting that needs to be presented to the user when the backend business module is executed (usually fails); ③ additional data attach that needs to be brought back when the backend business module is successfully executed. Considering that the data types and numbers returned by different backend business modules may vary, attach can be designed as the root class of the programming language (such as Java's Object) or the "key-value pair" type (such as Java's Map, Python's Dictionary, etc.).

[0067] Step 2: Write the front-end general verification logic for the request parameters related to the specific front-end business module (page) and the prompt copywriting M when the verification fails in each specific front-end business module. The front-end general verification logic here should be implemented declaratively (specified through the relevant attributes of the front-end UI library / component) rather than programmatically. When the request P is triggered by the user, execute this front-end general verification logic:

[0068] Step 2.1 If the verification is successful, go to Step 3;

[0069] Step 2.2 If the verification fails, pop up the prompt copywriting M, and this interaction process ends.

[0070] Step 3: Write a global request interceptor H for the front-end in a suitable form (different according to the front-end running platform, such as the XMLHttpRequest object and its encapsulation library natively supported by each web browser, the built-in interceptor class in each native APP platform, the API provided by each mini-program host environment, etc.) Req , where H Req describes all requests that need to be centrally processed in the front-end through a regular expression RE Front and determines whether P matches RE Front :

[0071] Step 3.1 If the match is successful:

[0072] Step 3.1.1 The front-end executes the operation logic corresponding to the request parameters included in the request P (such as parameter type conversion, removing leading and trailing whitespace characters from string parameters, escaping special characters included in string parameters, adding an authentication Token parameter, etc.);

[0073] Step 3.1.2 Trigger the corresponding UI rendering logic (such as displaying an indeterminate progress bar, popping up a mask layer with a waiting animation and prohibiting the user from repeating operations), and then go to Step 4.

[0074] In step 3.2, if the match fails, directly go to step 4.

[0075] Step 4: Write a global request interceptor H for the backend in a suitable form (such as a filter supported by each backend development technology, an interceptor supported by a relevant framework, etc.). Back , which describes all requests that need to be centrally processed at the backend through a regular expression RE Back ;

[0076] After the backend obtains the request P sent by the frontend, it determines whether the request P matches RE Back :

[0077] Step 4.1 If the match is successful, go to step 5:

[0078] Step 4.2 If the match fails, go to step 6.

[0079] Step 5: Write several backend general validation logics in a suitable form (such as Java language annotations, Python language decorators, etc.) according to the types of various request parameters that may be included in the request P, including but not limited to: ① Judge whether the parameter is empty; ② Judge whether the lengths of string type parameters and array type parameters are legal; ③ Judge whether the numeric type parameter is within a legal value range; ④ Judge whether the date / time type parameter is before or after the current date / time. Specifically:

[0080] Step 5.1 Before each formal parameter of the backend business module corresponding to the request P, configure 0 to N backend general validation logics in the form of metadata (data used to describe data, such as the attributes of annotations / decorators), where N is a positive integer;

[0081] Step 5.2 Through the reflection mechanism provided by the programming language, obtain each formal parameter Arg included in the request P and the metadata Meta of the backend general validation logic corresponding to the formal parameter Arg;

[0082] Step 5.3 Check whether all Args satisfy the validation logic with the corresponding Meta as the constraint condition:

[0083] Step 5.3.1 If all are satisfied, go to step 6;

[0084] Step 5.3.2 If at least one is not satisfied, construct a data structure R with succ as FALSE and msg as the prompt text corresponding to the self-validation logic of the backend business module, and then go to step 7;

[0085] Step 6: In the backend business module corresponding to request P, programmatically check whether each formal parameter of the backend business module meets the non-general verification logic and constraint conditions of the backend business module itself (such as whether the start and end time ranges exceed 1 month, whether the account to be logged in has been disabled by the administrator, whether the record to be deleted is being used, etc. These logics are related to specific businesses or involve multiple parameters, so the invasiveness cannot be eliminated by configuring metadata):

[0086] Step 6.1 If all are met, continue to execute the subsequent logic of the backend business module, construct an R object with succ as TRUE (msg and attach can be set according to business needs), and go to Step 7;

[0087] Step 6.2 If not met, construct an R data structure with succ as FALSE and msg as the prompt copy corresponding to the self-verification logic of the backend business module (attach can be set according to business needs), and then go to Step 7;

[0088] Step 7: Write the front-end global response interceptor H in an appropriate form (same as Step 3) Resp :

[0089] Step 7.1 Determine whether P and RE Front match:

[0090] Step 7.1.1 If the match is successful, end the UI rendering logic triggered before the front end (such as hiding the progress bar, closing the mask layer, etc.);

[0091] Step 7.1.2 If the match fails, go to 7.2;

[0092] Step 7.2 The front end obtains the R object returned in Step 5 or Step 6 (serialized in the form of JSON or XML, etc.), and judges the succ of R:

[0093] Step 7.2.1 If succ is FALSE, pop up a prompt copy with the content of R's msg to inform the user of the specific reason for the failure of this interaction, and then end this interaction process;

[0094] Step 7.2.2 If succ is TRUE, pass the attach in the R object to the request callback method of the specific front-end business module (page) (such as the Promise mechanism of the Web browser, the publish / subscribe mode implemented in various programming languages, etc.), and go to Step 8;

[0095] Step 8: Obtain H in the request callback method of each specific front-end business module (page) RespReturn the attached information, and based on the front-end business modules involved in this request P, update the relevant UI elements in the page or perform corresponding actions (such as popping up a business success message, jumping to a specified page, etc.). The current interaction process ends here.

[0096] It should be noted that the method of one or more embodiments of this specification can be executed by a single device, such as a computer or a server. The method of this embodiment can also be applied to a distributed scenario, and multiple devices cooperate with each other to complete it. In this case of a distributed scenario, one of these multiple devices can only execute one or more steps of the method of one or more embodiments of this specification, and these multiple devices will interact with each other to complete the described method.

[0097] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be executed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0098] Those of ordinary skill in the art should understand that: the discussion of any above embodiment is only exemplary and is not intended to imply that the scope of the present disclosure (including the claims) is limited to these examples; under the concept of the present disclosure, the technical features between the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations in different aspects of one or more embodiments of this specification as described above, which are not provided in detail for the sake of brevity.

[0099] The present invention aims to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A non-intrusive data interaction method in the scenario of front-end and back-end separation, characterized in that, Including: Set the front-end general verification logic in the front-end business module and configure the global request interceptor H in the front-end Req , where H Req describes all requests that need to be processed centrally at the front-end through the regular expression RE Front ; The front end obtains request P. If request P passes the verification in the front-end general verification logic, then it is judged whether request P matches RE Front If they do not match, request P is sent to the back end; if they match, after the front end executes the operation logic corresponding to the request parameters included in request P and / or triggers the corresponding UI rendering logic, request P is sent to the back end; Configure the global request interceptor H at the backend Back , where H Back describes all requests that need to be centrally processed at the backend through the regular expression RE Back ; Based on the types of request parameters, configure several backend general verification logics that are all adapted to the types, and configure 0 to N backend general verification logics for each formal parameter in the form of metadata before each formal parameter of the backend business module, where N is a positive integer; The backend obtains the request P sent by the frontend; if the request P matches RE Back If there is a match, the formal parameter Arg included in the request P and the metadata Meta of the backend general verification logic corresponding to the formal parameter Arg are obtained. If all the formal parameters Arg satisfy the backend general verification logic with the corresponding Meta as the constraint condition, and all the formal parameters Arg satisfy the self-verification logic of the backend business module, the backend executes the operation logic corresponding to the request parameters included in the request P and constructs a data structure R with succ = TRUE. Otherwise, a data structure R with succ = FALSE and msg as the prompt copy corresponding to the self-verification logic of the backend business module is constructed; if the request P does not match RE Back If there is no match, and all the formal parameters Arg satisfy the self-verification logic of the backend business module, the backend executes the operation logic corresponding to the request parameters included in the request P and constructs a data structure R with succ = TRUE. Otherwise, a data structure R with succ = FALSE and msg as the prompt copy corresponding to the self-verification logic of the backend business module is constructed; The backend serializes the data structure R and sends the serialized data structure R to the frontend; Configure the global response interceptor H at the front end Resp , where the H Resp receives the serialized data structure R sent by the back end. If the succ of the data structure R is FALSE, a prompt text with the content of the msg of the data structure R is popped up to end the current interaction; if succ is TRUE, the attach in the data structure R is passed to the request callback method of the corresponding front-end business module. In the request callback method, obtain the attach information returned by H Resp , and update the corresponding UI elements or perform corresponding actions in the front-end page according to the front-end business module involved in the request P to end the current interaction.

2. The non-invasive data interaction method according to claim 1, wherein Also including: Write the prompt text M when the verification fails in the frontend business module. If the request P fails the verification in the frontend general verification logic, return the prompt text M.

3. The non-invasive data interaction method according to claim 1, wherein Also including: The said H Resp After receiving the serialized data structure R sent by the backend, end the triggered UI rendering logic.

4. The non-intrusive data interaction method according to claim 1, wherein The data structure R includes: A boolean succ, used to mark whether the backend business module of the request is executed successfully; A string msg, used to store the text to be presented to the user when the backend business module finishes execution; Additional data attach, used to store the data required to update the corresponding UI elements in the frontend page after the backend business module is successfully executed. attach is designed as the root class of the programming language or the "key-value pair" type.

5. The non-invasive data interaction method according to claim 1, characterized in that, The frontend executes the operation logic corresponding to the request parameters included in the request P, including: parameter type conversion and / or removing the leading and trailing whitespace characters of string parameters and / or escaping the special characters included in string parameters and / or adding an authentication Token parameter.

6. The non-invasive data interaction method according to claim 1, characterized in that The frontend triggers the corresponding UI rendering logic, including: displaying an indeterminate progress bar and / or popping up a mask layer with a waiting animation and / or prohibiting the user from repeating operations.

7. The non-intrusive data interaction method according to claim 1, wherein Based on the type of the request parameters, configure several backend general verification logics adapted to the type, including: judging whether the request parameters are empty; and / or, Judging whether the lengths of string parameters and array parameters are legal; and / or, Judging whether the numerical parameters are within the legal value range; and / or, Judging whether the date / time type parameters are before or after the current date / time.

8. A non-invasive data interaction device in a scenario of front-end and back-end separation, characterized in that Including: Front-end configuration module, which is used to set front-end general verification logic in the front-end business module and set a global request interceptor H in the front-end Req , where H Req describes all requests that need to be centrally processed in the front-end through the regular expression RE Front ; The front-end acquisition module is used to enable the front-end to obtain a request P. If the request P passes the verification in the front-end general verification logic, it is determined whether the request P matches RE Front If not, the request P is sent to the back-end; if it matches, after the front-end executes the operation logic corresponding to the request parameters included in the request P and / or triggers the corresponding UI rendering logic, the request P is sent to the back-end; Backend configuration module, used to configure the global request interceptor H at the backend Back , where H Back describes all requests that need to be centrally processed at the backend through the regular expression RE Back ; based on the type of request parameters, configure several backend general verification logics that are all adapted to the type, and configure 0 to N backend general verification logics for each formal parameter in the form of metadata before each formal parameter in the backend business module, where N is a positive integer; Backend acquisition module, used to enable the backend to acquire request P sent by the frontend; if request P matches RE Back and obtain the formal parameter Arg included in request P and the metadata Meta of the backend general verification logic corresponding to the formal parameter Arg. If all formal parameters Arg meet the backend general verification logic with the corresponding Meta as the constraint condition, and all formal parameters Arg meet the self-verification logic of the backend service module, the backend executes the operation logic corresponding to the request parameters included in request P and constructs a data structure R with succ = TRUE. Otherwise, a data structure R with succ = FALSE and msg as the prompt text corresponding to the self-verification logic of the backend service module is constructed; if request P does not match RE Back and all formal parameters Arg meet the self-verification logic of the backend service module, the backend executes the operation logic corresponding to the request parameters included in request P and constructs a data structure R with succ = TRUE. Otherwise, a data structure R with succ = FALSE and msg as the prompt text corresponding to the self-verification logic of the backend service module is constructed; A serialization module, used to enable the backend to serialize the data structure R and send the serialized data structure R to the frontend; Response and Interaction Module, used to configure the global response interceptor H in the front end Resp , where the H Resp receives the serialized data structure R sent by the backend. If the succ of the data structure R is FALSE, a prompt text with the msg of the data structure R as the content is popped up to end the current interaction; if succ is TRUE, the attach in the data structure R is passed to the request callback method of the corresponding front-end business module, and the attach information returned by H Resp is obtained in the request callback method, and according to the front-end business module involved in the request P, the corresponding UI elements in the front-end page are updated or the corresponding actions are executed to end the current interaction.

Images