Parameter verification method and device, equipment, storage medium and computer program product

Abstract

The invention provides a parameter verification method and device, equipment, a storage medium and a computer program product. The method comprises the steps of determining a first script file stored locally and a second script file in a parameter management system, and performing first verification on the first script file and the second script file; under the condition that the first verification is passed, determining a first input parameter from the first script file, and generating an interface calling request based on the first input parameter; an interface calling request is sent to a second device, the interface calling request is used for the second device to perform second verification on the first input parameter, and a first output parameter corresponding to the first input parameter is output under the condition that the second verification is passed; and receiving the first output parameter, and performing third verification on the first output parameter based on the first script file to obtain a parameter verification result. According to the invention, the consistency of input parameters and output parameters among different devices can be improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a parameter verification method, device, equipment, storage medium and computer program product. Background Art

[0002] In software development, separation of front-end and back-end has become a common architectural pattern. The front-end is responsible for the display and interaction of the user interface, and the back-end is responsible for the implementation of business logic and data processing. The communication between the front-end and back-end is usually completed through the Hypertext Transfer Protocol (HTTP) request interface. Although the separation of front-end and back-end helps improve software development efficiency and maintainability, in the actual development process, there is a problem of inconsistent parameters between the front-end and back-end due to human factors or technical defects. Summary of the invention

[0003] The embodiments of the present application provide a parameter verification method, apparatus, device, storage medium and computer program product, which can improve the consistency of input parameters and output parameters between different devices, thereby solving the problem of parameter inconsistency caused by human factors or technical defects.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] An embodiment of the present application provides a parameter verification method, which is applied to a first device, and the method includes: determining a first script file stored locally and a second script file in a parameter management system, and performing a first verification on the first script file and the second script file; if the first verification passes, determining a first input parameter from the first script file, and generating an interface call request based on the first input parameter; sending the interface call request to a second device, wherein the interface call request is used for the second device to perform a second verification on the first input parameter, and if the second verification passes, outputting a first output parameter corresponding to the first input parameter; receiving the first output parameter, and performing a third verification on the first output parameter based on the first script file to obtain a parameter verification result.

[0006] An embodiment of the present application provides a parameter verification method, which is applied to a second device, and the method includes: determining a first software package stored locally and a second software package in a parameter management system, and performing a fourth verification on the first software package and the second software package; if the fourth verification passes, performing a second verification on a first input parameter in a received interface call request based on the first software package; if the second verification passes, determining a first output parameter corresponding to the first input parameter from the first software package; and sending the first output parameter to the first device, wherein the first output parameter is used for the first device to perform a third verification to obtain a parameter verification result.

[0007] An embodiment of the present application provides a parameter verification device, including: a first verification module, used to determine a first script file stored locally and a second script file in a parameter management system, and perform a first verification on the first script file and the second script file; an input parameter determination module, used to determine a first input parameter from the first script file when the first verification passes, and generate an interface call request based on the first input parameter; an interface call module, used to send the interface call request to a second device, wherein the interface call request is used for the second device to perform a second verification on the first input parameter, and when the second verification passes, output a first output parameter corresponding to the first input parameter; a parameter verification module, used to receive the first output parameter, and perform a third verification on the first output parameter based on the first script file to obtain a parameter verification result.

[0008] An embodiment of the present application provides an electronic device, the electronic device comprising:

[0009] A memory for storing computer executable instructions or computer programs;

[0010] The processor is used to implement the parameter verification method provided in the embodiment of the present application when executing the computer executable instructions or computer program stored in the memory.

[0011] An embodiment of the present application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the parameter verification method provided in the embodiment of the present application when executed by a processor.

[0012] An embodiment of the present application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, the parameter verification method provided in the embodiment of the present application is implemented.

[0013] The embodiments of the present application have the following beneficial effects:

[0014] By performing a first check on the first script file stored locally on the first device and the second script file in the parameter management system, the local first script file can be prevented from being tampered with, and the integrity and consistency of the first script file can be ensured. An interface call request is generated based on the first input parameter in the first script file, and the interface call request is sent to the second device. The first input parameter is checked for a second time by the second device. When the second check result is passed, the first output parameter corresponding to the first input parameter is output, so that the first device and the second device use the same first input parameter. By performing a third check based on the first script file again on the received first output parameter, a parameter check result is obtained, so that the first device and the second device use the same first output parameter. Therefore, the embodiment of the present application can improve the consistency of input parameters and output parameters between different devices through a multi-level check mechanism, thereby solving the problem of parameter inconsistency caused by human factors or technical defects. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a schematic diagram of the architecture of the parameter verification system provided in the embodiment of the present application;

[0016] Figure 2 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0017] Figure 3 This is a flow chart of the parameter verification method provided in the embodiment of the present application. Figure 1 ;

[0018] Figure 4 This is a flow chart of the parameter verification method provided in the embodiment of the present application. Figure 2 ;

[0019] Figure 5 This is a flow chart of the parameter verification method provided in the embodiment of the present application. Figure 3 ;

[0020] Figure 6 This is a flow chart of the parameter verification method provided in the embodiment of the present application. Figure 4 ;

[0021] Figure 7 This is another optional flow chart of the parameter verification method provided in the embodiment of the present application;

[0022] Figure 8 This is a flow chart of the parameter verification method provided in the embodiment of the present application. Figure 5 ;

[0023] Fig. 9 This is another optional flow chart of the parameter verification method provided in the embodiment of the present application;

[0024] Fig.10 It is a flowchart of the front-end and back-end development provided by the embodiment of the present application;

[0025] Fig.11 It is a flow chart of parameter management provided by an embodiment of the present application;

[0026] Fig.12 It is a schematic diagram of the process of front-end development provided by the embodiment of the present application;

[0027] Fig.13 It is a flowchart of the back-end development provided in the embodiment of the present application. DETAILED DESCRIPTION

[0028] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0029] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0030] In the following description, the terms "first\second\third" involved are merely used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0031] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0032] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as those commonly understood by those skilled in the art. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0033] The relevant data collection and processing in the embodiments of this application should be strictly in accordance with the requirements of relevant laws and regulations when applied in examples, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of authorization of laws and regulations and the personal information subject.

[0034] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0035] 1) Front-end (Client): Usually the application that users interact with directly, such as web pages, mobile applications, etc. The front-end is responsible for displaying the user interface, collecting user input, and converting user needs into interface call requests for the back-end interface.

[0036] 2) Interface: It is the service endpoint provided by the backend to the frontend for calling. It defines the method and parameters that allow the frontend to call. The interface usually includes a uniform resource location (URL) and query parameters, request body, etc. After receiving the interface call request from the frontend, the backend processes the interface call request according to the interface definition and returns the corresponding data or status.

[0037] 3) Backend (Server): Responsible for processing the interface call requests sent by the frontend, executing business logic, and interacting with data storage such as databases. According to the interface definition, it can receive interface call requests, process them, and then return HTTP responses. The HTTP response generated by the backend usually includes a status code (such as 200 for success, 404 for resource not found, etc.) and output parameters.

[0038] 4) Input Parameters: Input Parameters refer to the data sent by the front-end to the back-end interface, which is used to tell the back-end what operation needs to be performed and the conditions or data required for the operation. Input Parameters can include query parameters, which are usually appended to the URL in the form of key-value pairs. For example, / users? username=john&age=30, where username and age are query parameters.

[0039] 5) Output Parameters: Output Parameters are the response data returned to the front end after the back end processes the interface call request sent by the front end. Output Parameters include the result of the operation, status information, and other data that the front end may need to know. Output Parameters may include: Status Code: Indicates the execution result of the request, for example, 200 indicates success, 404 indicates resource not found, 500 indicates server error, etc.; Response Body: Contains the actual response data, which can be the result of the operation or information that needs to be displayed on the front end.

[0040] 6) Script file: refers to JavaScript (js) file, which is a programming file used to write input parameters and output parameters used in front-end development.

[0041] 7) Software package: refers to the jar (Java ARchive) package, which is a compressed file format used to package input parameters and output parameters used in back-end development.

[0042] 8) Field: In programming, a field is an attribute or variable in an object or data structure that is used to store data or status information. For example, a field can be a username, password, etc.

[0043] 9) Field value: The specific data value of the field. For example, the field value of the field "username" may be "Zhang San".

[0044] 10) Hash processing: The process of converting input data into a string of fixed length (hash value). The hash function ensures that the same input produces the same hash value, and different inputs produce different hash values.

[0045] 11) Hash value: A fixed-length string calculated by a hash function, usually used in scenarios such as quick search, data integrity verification, and encryption.

[0046] 12) Message Digest Algorithm 5 (MD5): is a commonly used hash function used to generate a 128-bit (16-byte) hash value.

[0047] 13) Parameter Management System: A system used to manage and maintain parameter settings and configurations during software development. It can store and update various input parameters and output parameters.

[0048] In order to better understand the parameter verification method provided in the embodiment of the present application, the front-end and back-end interaction processes in the related technology and the problems faced by the parameter verification method are first explained.

[0049] In the related art, when developing front-end and back-end services, the back-end is mainly responsible for designing the input and output parameters of the HTTP request interface. After the design is completed, the interface is provided for the front-end to use. When the user operates through the front-end application, the front-end will construct an HTTP request, which includes the method (GET, POST, etc.), URL and possible request body (such as data in JSON format). The front-end sends the HTTP request to the specified back-end through the network to convey the user's needs. After receiving the request, the back-end identifies the corresponding interface according to the URL and parameters of the request and processes the request, which may include querying the database, performing calculations, etc. After the back-end processes the request, it will generate an HTTP response, which includes a status code, a response body and possible header information. After the front-end receives the HTTP response from the back-end, it will parse the data in the response body and determine whether the operation is successful based on the response status code. In the specific business development process, although the front-end and the back-end can reduce the situation of missing input or output parameters with the support of the interface document, the usual situation is that when the back-end increases or decreases the input or output parameters, the interface document may not be updated in time, resulting in the front-end being unable to make corresponding parameter changes and causing problems with the function corresponding to a certain interface.

[0050] Based on the problems existing in the related art, the embodiments of the present application provide a parameter verification method, device, electronic device, computer-readable storage medium and computer program product, which can make the parameters used in the front and back ends of the development process consistent and improve the development efficiency. The following describes an exemplary application of the electronic device provided by the embodiment of the present application. The electronic device provided by the embodiment of the present application can be implemented as various types of terminals such as laptops, tablet computers, desktop computers, set-top boxes, smart phones, smart speakers, smart watches, smart TVs, and vehicle-mounted terminals, and can also be implemented as servers. Below, an exemplary application when the electronic device is implemented as a terminal or a server will be described.

[0051] See also Figure 1 , Figure 1 1 is a schematic diagram of the architecture of the parameter verification system provided in the embodiment of the present application. The parameter verification system 100 in the embodiment of the present application at least includes a terminal 400, a network 300 and a server 200. The terminal 400 is connected to the server 200 via the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two.

[0052] In the front-end and back-end business development scenario, the first device is the terminal 400 and the second device is the server 200. Figure 1, the user can start the front-end system operation through the terminal 400. In response to the start-up front-end system operation, the terminal 400 determines the first script file stored locally and the second script file in the parameter management system, and performs a first check on the first script file and the second script file. If the first check passes, the front-end system starts, and the user performs an interactive operation through the client of the front-end system. The interactive operation may be an interface selection operation, a parameter value input operation, etc. In response to the interactive operation, the terminal 400 determines the first input parameter from the first script file, and generates an interface call request based on the first input parameter; the terminal 400 sends the interface call request to the server 200 through the network 300; after receiving the interface call request, the server 200 performs a second check on the first input parameter in response to the interface call request, and outputs the first output parameter corresponding to the first input parameter if the second check passes; the terminal 400 receives the first output parameter, and performs a third check on the first output parameter based on the first script file to obtain a parameter check result. When the parameter verification result is successful, the terminal 400 develops business based on the received first output parameter; or, when the parameter verification result is failed, the terminal 400 develops business based on the received first output parameter, and the terminal 400 displays a prompt message of parameter verification failure on the current interface.

[0053] See also Figure 2 , Figure 2 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application, Figure 2 The terminal 400 shown includes: at least one processor 410, a memory 450, at least one network interface 420 and a user interface 430. The various components in the terminal 400 are coupled together via a bus system 440. It is understood that the bus system 440 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 440 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 440 is not shown in FIG. Figure 2 Various buses are labeled as bus system 440 .

[0054] The processor 410 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0055] The user interface 430 includes one or more output devices 431 that enable presentation of media content, including one or more speakers and / or one or more visual display screens. The user interface 430 also includes one or more input devices 432, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0056] The memory 450 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 450 may optionally include one or more storage devices that are physically remote from the processor 410.

[0057] The memory 450 includes a volatile memory or a non-volatile memory, and may also include both volatile and non-volatile memories. The non-volatile memory may be a read-only memory (ROM), and the volatile memory may be a random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0058] In some embodiments, memory 450 can store data to support various operations, examples of which include programs, modules, and data structures, or a subset or superset thereof, as exemplarily described below.

[0059] Operating system 451, including system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0060] A network communication module 452, used to reach other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 include: Bluetooth, Wireless Compatibility Certification (WiFi), and Universal Serial Bus (USB), etc.;

[0061] a presentation module 453 for enabling presentation of information via one or more output devices 431 (e.g., display screen, speaker, etc.) associated with the user interface 430 (e.g., a user interface for operating peripherals and displaying content and information);

[0062] The input processing module 454 is used to detect one or more user inputs or interactions from one of the one or more input devices 432 and translate the detected inputs or interactions.

[0063] In some embodiments, the parameter verification device provided in the embodiments of the present application can be implemented in software. Figure 2 The parameter checking device 455 stored in the memory 450 is shown, which can be software in the form of a program and a plug-in, etc., and includes the following software modules: a first checking module 4551, an input parameter determination module 4552, an interface calling module 4553 and a parameter checking module 4554. These modules are logical, and therefore can be arbitrarily combined or further split according to the functions implemented. The functions of each module will be described below.

[0064] In other embodiments, the parameter verification device provided in the embodiments of the present application can be implemented in hardware. As an example, the device provided in the embodiments of the present application can be a processor in the form of a hardware decoding processor, which is programmed to execute the parameter verification method provided in the embodiments of the present application. For example, the processor in the form of a hardware decoding processor can adopt one or more application-specific integrated circuits (Application Specific Integrated Circuit, ASIC), digital signal processors (Digital Signal Processor, DSP), programmable logic devices (Programmable Logic Device, PLD), complex programmable logic devices (Complex Programmable Logic Device, CPLD), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other electronic components.

[0065] Figure 3 This is a flow chart of the parameter verification method provided in the embodiment of the present application. Figure 1 , will combine Figure 3 The steps shown are explained as Figure 3 As shown, the parameter verification method is described by taking the execution subject of the first device as an example, and the method includes the following steps 101 to 104:

[0066] In step 101, a first verification is performed on a first script file stored locally and a second script file in a parameter management system to obtain a first verification result.

[0067] Here, first determine the first script file stored locally and the second script file in the parameter management system. The first device can be a terminal, that is, the front end in a business or software development scenario. Developers can configure and manage the input parameters and output parameters corresponding to each business system in the parameter management system in advance. The input parameters and output parameters corresponding to each business system can be packaged into js files and jar packages, and the js file is the second script file. First, select the business system to be developed, and the terminal downloads the second script file corresponding to the business system from the parameter management system, and stores it locally to obtain the first script file. When developing the front and back ends, since the first script file stored locally may change due to manual or technical errors, before the front-end system is started, the terminal needs to perform a first check on the first script file stored locally and the second script file in the parameter management system to obtain a first check result. The embodiment of the present application does not limit the specific method of the first check, for example, the first check can be to check whether the file contents of the first script file and the second script file are consistent, or the first check can also be to check whether the version number of the first script file is consistent with the version number of the second script file. If the first check result is passed, the front-end system starts. If the first check result is failed, the front-end system cannot be started, and a parameter check result of failed check is obtained. The parameter verification result can be displayed on the current interface of the terminal, such as a prompt message with the text "startup failure". Based on the prompt message, the front-end developer can re-download the second script file from the parameter management system and then start the front-end system.

[0068] In an embodiment of the present application, a first verification is performed on a first script file stored locally and a second script file in a parameter management system, which can be achieved in the following manner: first, hash processing is performed on the first script file to obtain a first hash value; then, a second hash value of the second script file is determined from the parameter management system; finally, the first hash value and the second hash value are compared.

[0069] Here, the first check is to check whether the file contents of the first script file and the second script file are consistent. Whether the file contents of the first script file and the second script file are consistent can be confirmed by comparing the hash values ​​of the first script file and the second script file. The embodiment of the present application does not limit the hash function used for hash processing. For example, the terminal can use the MD5 hash function to hash the first script file to obtain a first hash value. Similarly, the parameter management system uses the MD5 hash function to hash the second script file to obtain a second hash value. The terminal obtains the second hash value from the parameter management system and compares the first hash value and the second hash value. When the first hash value and the second hash value are the same, the first check result is passed; when the first hash value and the second hash value are different, the first check result is failed.

[0070] The embodiment of the present application compares the hash values ​​of the first script file and the second script file to confirm whether the file contents of the first script file and the second script file are consistent, which can improve the verification efficiency of the first script file and the second script file, prevent the locally stored first script file from being tampered with, and improve the front-end and back-end development efficiency.

[0071] In step 102, when the first verification result is passed, a first input parameter is determined from the first script file, and an interface call request is generated based on the first input parameter.

[0072] Here, if the first verification result passes, the front-end system is started. The user can perform an operation of selecting a business system to be developed on the front-end system through the terminal, and the terminal determines the first script file corresponding to the business system to be developed from the first script file. Among them, the business system includes multiple functions, and each function corresponds to an interface. The first script file includes input parameters corresponding to multiple interfaces. The user can perform an operation of selecting a function to be developed on the front-end system through the terminal, and the terminal determines the interface path corresponding to the function to be developed, and determines the first input parameter corresponding to the interface path from the first script file. The terminal encapsulates the first input parameter and the interface path into the interface call request.

[0073] In some embodiments, the first input parameter includes a third field. Figure 4 In step 102, based on the first input parameter, an interface call request is generated, which can be implemented by following steps 1021 to 1023, which are described in detail below.

[0074] In step 1021, a second field value of the third field is determined.

[0075] Here, the first input parameter may include at least one third field. The third field may be any specific data item, such as user name, operation type, operation time and other information. The terminal may determine the page component information corresponding to each third field from the first script text, and render the page component corresponding to each third field on the page of the previous system based on the page component information. The page component information may include input box style information, drop-down box style information, etc. The second field value is specific data of the third field, such as integer type value, string type data, etc. The user may perform an operation of inputting the second field value through the terminal, and the terminal determines the second field value of each third field in response to the operation of inputting the second field value. Exemplarily, the first input parameter is an input parameter corresponding to the user login function, and the first input parameter may include two third fields: user name and user password. The page component information corresponding to the user name is the drop-down box style information, and the page component information corresponding to the user password is the input box style information. The terminal renders the user name in a drop-down box on the page, and renders the user password in an input box on the page. The user may select a specific second field value, such as "Zhang San", by clicking in the drop-down box corresponding to the user name, and the user may enter a specific second field value, such as "abc" externally in the input box corresponding to the user password.

[0076] In step 1022, a fourth field is determined from the third field.

[0077] Among them, the fourth field is the third field with an associated relationship.

[0078] Here, the association relationship is the relationship between the fields of multiple third fields pre-defined in the first script file. The second field value of the third field with an association relationship satisfies the preset constraint condition. The terminal determines at least two fourth fields from the multiple third fields. For each third field with an association relationship, the third field is determined as the fourth field, and the second field value of the third field is determined as the third field value of the fourth field. For at least two fourth fields, the constraint condition refers to the value range or field value type of the third field value of one of the fourth fields, which is constrained by the value range or field value type of the third field value of another fourth field. The field value type may include integer type, string type, floating point type, etc. Exemplarily, the function of the business system is a product information filling function. Assuming that there are 100 pieces of inventory for product size L, the product size and product quantity are two fourth fields, and the constraint condition is that when the third field value of the fourth field "product size" is "L", the third field value of the fourth field "product quantity" must be less than or equal to 100.

[0079] In step 1023, when the constraint condition is satisfied between the third field value of the fourth field, an interface call request is generated based on the third field and the second field value.

[0080] Here, for at least two fourth fields, it can be determined whether the third field values ​​of the fourth fields meet the constraint conditions. When each fourth field meets the constraint conditions, the terminal can encapsulate multiple third fields and the second field value of each third field into the interface call request. When at least one fourth field does not meet the constraint conditions, a parameter verification result of verification failure is obtained. The terminal can display the parameter verification result in real time. For example, the parameter verification result can be displayed as the field name of the fourth field that does not meet the constraint conditions, and the specific reason for not meeting the constraint conditions, so that the front-end developer can re-enter the third field value of the fourth field.

[0081] The embodiment of the present application determines the association relationship between the third fields and verifies whether the second field values ​​of the third fields with the association relationship meet the constraint conditions. The terminal can check in real time whether the parameters meet the specifications and display the reasons for the parameter failure, thereby improving the front-end development efficiency.

[0082] In step 103, an interface calling request is sent to the second device.

[0083] The interface call request is used for the second device to perform a second check on the first input parameter to obtain a second check result, and when the second check result is passed, output a first output parameter corresponding to the first input parameter.

[0084] Here, the second device can be a server, that is, the backend in the business or software development scenario. The terminal sends the interface call request to the server. It should be noted that at this time, the backend system in the server has been started. The jar package of the same business system as the first script file used by the terminal in the parameter management system is the second software package. The server downloads the second software package corresponding to the business system from the parameter management system and stores it locally to obtain the first software package. When developing the front and back ends, since the first software package stored locally may change due to manual or technical errors, before the back-end system is started, the server needs to perform a fourth check on the first software package stored locally and the second software package in the parameter management system to obtain a fourth check result. The specific process of the fourth check can refer to the first check in step 101, which will not be repeated here. If the fourth check result is passed, the back-end system is started. If the fourth check result is failed, the back-end system cannot be started, and a parameter check result of a failed check is obtained. The back-end developer can download the second software package from the parameter management system again and start the back-end system again.

[0085] If the fourth check is passed, the backend system is started. The server can accept the interface call request through the interface in the backend system, and the server responds to the interface call request and obtains the interface path in the interface call request. A second input parameter corresponding to the interface path is obtained from the first software package, and a second check is performed on the first input parameter based on the second input parameter to obtain a second check result. If the second check result is passed, a first output parameter corresponding to the first input parameter is determined from the first software package, and the first output parameter is sent to the terminal.

[0086] In step 104, a first output parameter is received, and a third check is performed on the first output parameter based on the first script file to obtain a parameter check result.

[0087] Here, the terminal receives the first output parameter and determines the second output parameter corresponding to the interface path from the first script file. The first output parameter is subjected to a third check based on the second output parameter to obtain a parameter check result. When the parameter check result is a successful check, the front-end and back-end function development continues. When the parameter check result is a failed check, the reason for the parameter check failure is displayed on the current interface of the terminal for the front-end developer to troubleshoot the error.

[0088] The embodiment of the present application can prevent the local first script file from being tampered with and ensure the integrity and consistency of the first script file by performing a first check on the first script file stored locally on the first device and the second script file in the parameter management system. An interface call request is generated based on the first input parameter in the first script file, and the interface call request is sent to the second device. The first input parameter is checked for a second time by the second device. When the second check result is passed, the first output parameter corresponding to the first input parameter is output, so that the first device and the second device use the same first input parameter. By performing a third check based on the first script file again on the received first output parameter, a parameter check result is obtained to ensure that the first device and the second device use the same first output parameter. Therefore, the embodiment of the present application can improve the consistency of input parameters and output parameters between different devices through a multi-level check mechanism, thereby solving the problem of parameter inconsistency caused by human factors or technical defects.

[0089] In some embodiments, see Figure 5 In step 104, a third check is performed on the first output parameter based on the first script file to obtain a parameter check result, which can be achieved by following steps 1041 to 1043, which are described in detail below.

[0090] In step 1041, based on the first parameter type of the first output parameter, a mapping table is queried.

[0091] The mapping table includes the corresponding relationship between parameter types and level verification methods.

[0092] Here, the first parameter type is a parameter type obtained by classifying multiple first output parameters based on different level verification methods. The embodiment of the present application does not limit the specific form of expression of the parameter type. For example, it can be represented by letters or numbers, and the number of parameter types can be set by the user. The level verification method is used to indicate the verification level of the first output parameter, which reflects the number of verifications that the first output parameter needs to go through. The mapping table is a table for storing the correspondence between different parameter types and different level verification methods. The terminal can determine the first parameter type of the first output parameter and query the level verification method corresponding to the first parameter type from the mapping table.

[0093] Exemplarily, the parameter types include two types, A and B, and the level verification methods may include first-level and second-level verification methods. The number of verifications in the first-level verification method is greater than the number of verifications in the second-level verification method. For example, the first-level verification method includes quantity verification, name verification, and field value verification. The second-level verification method only includes quantity verification. Parameter type A indicates that the first output parameter needs to be paid special attention to. Parameter type A corresponds to the first-level verification method in the mapping table. For example, for the first output parameter involving funds, three types of verifications can be performed: quantity, name, and field value rules; parameter type B indicates that the first output parameter does not need to be paid attention to. Parameter type B corresponds to the second-level verification method in the mapping table. For example, for optional parameters, only quantity verification can be performed.

[0094] In step 1042, the level verification method corresponding to the first parameter type found out is determined as the first level verification method of the first output parameter.

[0095] Here, the terminal searches the mapping table for the level verification method corresponding to the first parameter type, and determines the level verification method as the first level verification method of the first output parameter.

[0096] In step 1043, based on the first script file, a level check is performed on the first output parameter according to a first level check method to obtain a parameter check result.

[0097] Here, the terminal determines the second output parameter corresponding to the interface path from the first script file. Based on the second output parameter, the first output parameter is level-checked according to the first level-check method to obtain a parameter check result. When the parameter check result is a successful check, the front-end and back-end function development continues. When the parameter check result is a failed check, the reason for the parameter check failure is displayed on the current interface of the terminal for the front-end developer to troubleshoot the error.

[0098] The embodiment of the present application divides the first input parameter according to the parameter type, and different parameter types correspond to different level verification methods. It can achieve multi-level verification only for the first input parameter that is of focus, and only simple verification for the first input parameter that does not need to be paid attention to, thereby improving the parameter verification efficiency and further improving the development efficiency.

[0099] In some embodiments, the level check corresponding to the first level check method includes quantity check, name check and field value check, and the first output parameter includes the first field and the first field value of the first field. In step 1043, based on the first script file, the first output parameter is level checked in accordance with the first level check method to obtain the parameter check result, which can be achieved in the following way: first, the second output parameter corresponding to the first input parameter is determined from the first script file, and the quantity of the first field and the second field included in the second output parameter are checked in quantity; then, if the quantity check passes, the name of the first field and the name of the second field are checked in name; finally, if the name check passes, the first field value is checked in field value based on the field value rule of the first field to obtain the parameter check result, wherein the field value rule is used to limit the type and range of the first field value.

[0100] Here, the first output parameter includes at least one first field and a first field value of the first field. The first field value of the first field is obtained by querying or calculating the first input parameter by the server based on the parameter rule in the first software package. The terminal determines the second output parameter corresponding to the first input parameter from the first script file, that is, determines the second output parameter corresponding to the interface path from the first script file. The second output parameter includes at least one second field. The terminal performs a quantity check on the number of the first field and the number of the second field. When the number of the first field and the number of the second field are the same, the quantity check passes, and the name check continues. When the number of the first field and the number of the second field are different, the quantity check fails, and a parameter check result of failed check is obtained. The terminal performs a name check on the name of each first field and the name of each second field. When the name of each first field can find the same name of the second field, the name check succeeds, and a field value check can be performed. When the name of at least one first field cannot find the same name of the second field, the name check fails, and a parameter check result of failed check is obtained. For each first field, the terminal performs a field value check on the first field value of the first field based on the field value rule of the first field. The field value rule includes a value range and a field value type of the first field value. When the first field value is within the value range defined by the field value rule, and the type of the first field value is the same as the field value type defined by the field value rule, a parameter verification result indicating successful parameter verification is obtained. At this time, the first output parameter is used for front-end and back-end function development. When the first field value is outside the value range defined by the field value rule, or the type of the first field value is different from the field value type defined by the field value rule, a parameter verification result indicating failed parameter verification is obtained.

[0101] The embodiment of the present application can improve the accuracy of parameter verification by performing three-level verification of the quantity, name and field value of the first output parameter, thereby ensuring the consistency of parameters used in the front-end and back-end development processes.

[0102] In some embodiments, see Figure 6 Before generating an interface call request based on the first input parameter in step 102, the parameter verification method provided in the embodiment of the present application further includes the following steps 201 to 203:

[0103] In step 201, feature extraction is performed on behavior data of an account corresponding to a first device to obtain behavior features.

[0104] Here, the account corresponding to the first device is the account of the front-end system of the user logging into the terminal. The behavior data of the account may include the user's interaction time, interaction frequency, access path, and the first input parameter of the user's historical interaction. The terminal can use a convolutional neural network to extract features from the behavior data to obtain a vector representation, which is the behavior feature.

[0105] In step 202, an abnormality detection process is performed on the behavior characteristics to obtain abnormal parameter values.

[0106] Here, the terminal can use a pre-trained anomaly detection model to perform anomaly detection on the behavior feature to obtain an anomaly parameter value. The anomaly parameter value is a probability value used to characterize whether the behavior feature conforms to the historical behavior of the account. The embodiment of the present application does not limit the model structure of the anomaly detection model, for example, it can be a machine learning model.

[0107] In step 203, when the abnormal parameter value is less than the first threshold, it is determined to execute an operation of generating an interface call request based on the first input parameter.

[0108] Here, the first threshold is a critical value used to indicate whether the behavior data of the account is abnormal. When the abnormal parameter value is less than the first threshold, the behavior data of the account is normal, and the operation of generating an interface call request based on the first input parameter is determined to be executed. When the abnormal parameter value is greater than or equal to the first threshold, the behavior data of the account is abnormal, and a parameter verification result indicating that the parameter verification failed is obtained. At this time, a prompt message of "account abnormality" can be displayed on the current interface of the terminal.

[0109] In the embodiment of the present application, before generating an interface call request based on the first input parameter, the terminal first detects the behavior data of the account, thereby ensuring that the current account is operated by the user himself, thereby ensuring the security of front-end and back-end development.

[0110] Figure 7 is another optional flow chart of the parameter verification method provided in the embodiment of the present application, which will be combined with Figure 7 The steps shown are explained as Figure 7 As shown, the parameter verification method is described by taking the execution subject of the second device as an example, and the method includes the following steps 301 to 304:

[0111] In step 301, a fourth verification is performed on the first software package stored locally and the second software package in the parameter management system to obtain a fourth verification result.

[0112] Here, first determine the first software package stored locally and the second software package in the parameter management system. The second device can be a server, that is, the backend in the business or software development scenario. Developers can configure and manage the input parameters and output parameters corresponding to each business system in the parameter management system in advance. The input parameters and output parameters corresponding to each business system can be packaged into js files and jar packages, and the jar package is the second software package. First, select the business system to be developed, and the server downloads the second software package corresponding to the business system from the parameter management system and stores it locally to obtain the first software package. When developing the front and back ends, since the first software package stored locally may change due to manual or technical errors, before the back-end system is started, the server needs to perform a fourth check on the first software package stored locally and the second software package in the parameter management system to obtain a fourth check result. The specific process of the fourth check can refer to the first check in step 101, which will not be repeated here. If the fourth check result is passed, the back-end system is started. If the fourth check result is failed, the back-end system cannot be started, and the parameter check result of the check failure is obtained. The back-end developer can download the second software package from the parameter management system again and then start the back-end system.

[0113] In step 302, when the fourth verification result is passed, a second verification is performed on the first input parameter in the received interface call request based on the first software package to obtain a second verification result.

[0114] Here, in the case where the fourth verification result is passed, the back-end system is started. The server can accept the interface call request through the interface in the back-end system, and the server responds to the interface call request to obtain the interface path in the interface call request. The second input parameter corresponding to the interface path is obtained from the first software package. The first input parameter in the received interface call request is subjected to a second verification based on the second input parameter to obtain a second verification result. The second verification refers to verifying the number and name of the third field in the first input parameter and the number of the fifth field in the second input parameter. When the number of the third field in the first input parameter is the same as the number of the fifth field in the second input parameter, and the name of the third field in the first input parameter is the same as the name of the fifth field in the second input parameter, the second verification result is passed. Alternatively, when the number of the third field in the first input parameter is different from the number of the fifth field in the second input parameter, or at least one third field in the first input parameter cannot determine the fifth field of the same name from the second input parameter, the second verification result is failed.

[0115] In step 303, when the second verification result is passed, a first output parameter corresponding to the first input parameter is determined from the first software package.

[0116] Here, if the second verification result is passed, the server can determine the first output parameter corresponding to the first input parameter from the first software package based on the interface path. The first output parameter includes multiple first fields, and the server can query or calculate the first field value of each first field based on the first input parameter according to the parameter rule in the first software package. If the second verification result is failed, the server sends the parameter verification result of the failed verification to the terminal.

[0117] In step 304, a first output parameter is sent to the first device.

[0118] The first output parameter is used for the first device to perform a third verification to obtain a parameter verification result.

[0119] Here, the server sends the first output parameter to the terminal, and the terminal performs the third verification. The specific process of obtaining the parameter verification result can refer to the above step 104, and will not be repeated.

[0120] The embodiment of the present application performs a second check on the first input parameter sent by the terminal through the server side, thereby ensuring the integrity and consistency of the first input parameter during the transmission process, thereby improving the security and efficiency of front-end and back-end development.

[0121] In some embodiments, the interface call request includes a first timestamp. Figure 8 Before performing a second check on the first input parameter in the received interface call request based on the first software package in step 302, the parameter checking method provided in the embodiment of the present application further includes the following steps 401 to 403:

[0122] In step 401, a second timestamp when an interface call request is received is determined.

[0123] Here, the first timestamp and the second timestamp can be represented by specific time information, such as date, hour and minute, etc. The first timestamp is the time information when the terminal sends the interface call request. The second timestamp is the time information when the server receives the interface call request.

[0124] In step 402, when the difference between the second timestamp and the first timestamp is greater than or equal to a preset threshold, a parameter verification result indicating verification failure is sent to the first device.

[0125] Here, the preset threshold is a critical value for indicating whether the time interval between the server receiving the interface call request and the terminal sending the interface call request is abnormal. The server can calculate the difference between the second timestamp and the first timestamp. When the difference between the second timestamp and the first timestamp is greater than or equal to the preset threshold, the time interval between the server receiving the interface call request and the terminal sending the interface call request is abnormal, and the interface call request may be tampered with during transmission. Therefore, a parameter verification result of verification failure is sent to the terminal.

[0126] In step 403, when the difference is less than the preset threshold, it is determined to perform a second check on the first input parameter in the interface call request based on the first software package.

[0127] Here, when the difference between the second timestamp and the first timestamp is less than the preset threshold, the time interval between the server receiving the interface call request and the terminal sending the interface call request is normal, and it is determined to perform a second check on the first input parameter in the interface call request based on the first software package.

[0128] The embodiment of the present application adds a check on the time interval between the server receiving the interface call request and the terminal sending the interface call request before the server performs the second check on the first input parameter, thereby ensuring the integrity and consistency of the first input parameter during the transmission process and improving the front-end and back-end development efficiency.

[0129] Fig. 9 is another optional flow chart of the parameter verification method provided in the embodiment of the present application, such as Fig. 9 As shown, the method includes the following steps 501 to 510:

[0130] Step 501: The terminal performs a first verification on a first script file stored locally and a second script file in a parameter management system to obtain a first verification result.

[0131] Here, a first verification is performed on the locally stored first script file and the second script file in the parameter management system. The specific process of obtaining the first verification result can refer to step 101 in the above embodiment and will not be repeated.

[0132] Step 502: When the first verification result is passed, the front-end system is started, and the terminal receives the user's interactive operation through the front-end system.

[0133] Here, the interactive operation may be an interface selection operation, a parameter value input operation, and the like.

[0134] Step 503: In response to the interactive operation, the terminal determines a first input parameter from the first script file, and generates an interface call request based on the first input parameter.

[0135] Here, the specific process of determining the first input parameter from the first script file and generating the interface call request based on the first input parameter can refer to step 102 in the above embodiment, and will not be repeated.

[0136] Step 504: The terminal sends an interface call request to the server.

[0137] Step 505: The server determines the first software package stored locally and the second software package in the parameter management system, and performs a fourth verification on the first software package and the second software package to obtain a fourth verification result.

[0138] Here, the locally stored first software package and the second software package in the parameter management system are determined, and the first software package and the second software package are subjected to a fourth verification. The specific process of obtaining the fourth verification result can refer to step 301 in the above embodiment, and will not be repeated.

[0139] Step 506: When the fourth verification result is passed, the backend system is started, and the server receives the interface call request sent by the terminal through the backend system.

[0140] Step 507: In response to the interface call request, the server performs a second check on the first input parameter in the received interface call request based on the first software package to obtain a second check result.

[0141] Here, the specific process of performing a second check on the first input parameter in the received interface call request based on the first software package and obtaining the second check result can refer to step 302 in the above embodiment, and will not be repeated.

[0142] Step 508: When the second verification result is passed, the server determines the first output parameter corresponding to the first input parameter from the first software package.

[0143] Here, the specific process of determining the first output parameter corresponding to the first input parameter from the first software package can refer to step 303 in the above embodiment, and will not be repeated here.

[0144] Step 509: The server sends the first output parameter to the terminal.

[0145] Step 510: The terminal receives the first output parameter, and performs a third check on the first output parameter based on the first script file to obtain a parameter check result.

[0146] Here, the specific process of performing the third check on the first output parameter based on the first script file to obtain the parameter check result can refer to step 104 in the above embodiment, and will not be repeated.

[0147] The embodiment of the present application verifies the first script file stored locally by the terminal, and verifies the first software package stored locally by the server, which can prevent the local first script file or the first software package from being tampered with, and ensure the integrity and consistency of the first script file and the first software package. The terminal performs a third check on the first output parameter, and the server performs a second check on the first input parameter, which can ensure that the parameters used during development at both ends of the terminal and the server are consistent, thereby improving software development efficiency.

[0148] The following is an explanation of an exemplary application of an embodiment of the present application in a practical application scenario.

[0149] In order to solve the problem of consistency of front-end and back-end parameters, the embodiment of the present application develops a separate parameter management system, in which the output parameters (i.e., output parameters) and input parameters (i.e., input parameters) of specific applications (business systems) and specific interfaces can be uniformly defined, and the compiled and packaged jar package for use by the back-end (corresponding to the second software package in the above embodiment) and the generated js file for use by the front-end (corresponding to the second script file in the above embodiment) are consistent in version to prevent modification during use, the back-end performs a consistency check on the input parameters (corresponding to the second check in the above embodiment), and the front-end performs a consistency check on the output parameters (corresponding to the third check in the above embodiment), thereby reducing the situation where problems with the corresponding functions of the interface due to parameter mismatch, thereby improving the development efficiency and collaboration of the front-end and back-end.

[0150] Fig.10 This is a flow chart of the front-end and back-end development provided by the embodiment of this application. Fig.10, step 601, define the input and output parameters of the function. The back-end developers uniformly design and define the input and output parameters of a certain function of a business system (one function corresponds to one interface) in the parameter management system. Step 602, generate the jar package and js file of the input and output parameters. After designing and defining the input and output parameters of all functions, the jar package and js file of the input and output parameters can be generated. Step 603, the front end downloads the js file. The front end manually downloads the js file of the input and output parameters, introduces the js file into the front-end system being developed, and uses the js file to develop a certain page function of the front end. Step 604, obtain the input and output parameters. When developing a certain function of the front end, according to the back-end interface to be called by the function, the input and output parameters required for the development of the function can be taken out from the locally cached js file according to the interface path. Step 605, dynamically render the input parameters in the page. According to the configuration and rules of the input parameter definition, the input parameters in the dynamic rendering page may need to be displayed for some input parameters, and some functions may need to hide the input parameters. Step 606, call the back-end interface function. Call the backend interface function (here it is assumed that the backend service has developed the corresponding backend function using the input and output parameter jar packages, and can accept HTTP requests initiated by the frontend). Step 607, obtain the output parameter value based on the returned parameters and the output parameter field, and dynamically render the page. According to the output parameter configuration and rules, the output parameter value returned by the backend (corresponding to the first field value in the above embodiment) is used to dynamically render the result page. If the input parameter verification fails, it will prompt that a certain parameter is wrong. If the returned output parameter does not match, it will also prompt that the output parameter is wrong. Step 608, front-end and back-end development functions. The front-end and back-end work together to develop a certain function, and the development is completed.

[0151] Fig.11It is a flow chart of parameter management provided by an embodiment of the present application. Step 701, log in to the parameter management system. The back-end developer logs in to the parameter management system to design the back-end interface. Step 702, configure the system to which the interface belongs and the request path. First, configure the request interface path and the specific business system to which the interface path belongs. For example, in the URL https: / / xxx.example.com / v1 / users / 123?, v1 / users / 123 is the interface path. Step 703, configure the input parameters of the interface. When configuring a specific interface, the input parameters of the interface path are configured. The input parameters can be selected by selecting fields in certain tables of a specific database, or by importing fields from a table generated by a structured query language (SQL) statement, or by manually entering them. For example, if the data required by the interface comes directly from the database, the corresponding database tables and fields need to be specified. The user registration interface may require fields such as user name username, email, and password password from the users table. If it is found that some fields can be used as public fields, these fields can be added to the public fields. When configuring the input parameters of the interface, fields can also be selected from some public fields. Public fields are just for the convenience of public use and reuse, avoiding repeated definition of many fields. For example, the primary key user identification (id) field, whether to delete the field, the time of adding, the time of modification, the person who added and the person who modified, and other fields that are needed in each table can be configured as public fields. Here, the fields with high usage rate are configured as public fields. After selecting the fields, the specific details of the backend and the frontend can be refined. The refined configuration of the frontend is mainly used to generate the frontend page components, and the refined configuration of the backend is mainly used to generate java class files, and finally compile and produce class files. Step 704, configure the class name corresponding to the input parameter. The java class name of the parent and child classes can be defined according to the specific situation. The parent class java class name includes some public fields (such as user id, ID number), and the child class java class name includes a specific field dedicated to a certain function (such as the unique field of the user registration interface, email and password). After the parent class is defined, it can also be used in step 703 to quickly define the input parameter field by selecting a parent class. For example, define a student information parent class, where name and student ID can be used as common fields of the student information parent class. There is a parent class field configuration interface in the parameter management system. When adding, modifying, or paging queries, the student information parent class can be used for both input and output parameters to avoid repeated definitions. Step 705: Configure the output parameters of the interface. To configure the interface path output parameter field, refer to step 703. Step 706: Configure the class name corresponding to the output parameter. Refer to step 704. Step 707: Save the data to the configuration table. Save the configured input and output parameter information of the interface path to the configuration table. Step 708: Select a business system.If you want to generate the input and output parameter jar package and js file used by the backend of a specific business system, select a business system to which it belongs. Step 709, export the configured input and output parameter classes. After exporting the configured input and output parameter classes according to the java class name, the input and output parameter classes are automatically encoded and packaged into a jar package and uploaded to the Maven service (Maven RepositoryService, a warehouse service) so that the backend system can introduce the jar package in the Maven configuration pom.xml (Project Object Model, core configuration file) when developing specific functions. The parameter management system provides an interface that can verify whether the jar package is the latest version and whether it has been modified. During the development and testing process, the business system needs to call this interface when starting the backend system to verify whether the locally introduced jar package is the latest version and valid, otherwise it will fail to start. Verification process: Use the MD5 value generated by the content of the jar file to verify whether the MD5 value is the same as the MD5 of the jar file in the parameter management system. Step 710, generate a js file. After selecting a business system, you can generate js files for the input and output parameters of all interfaces defined by the business system. The parameter management system provides an interface to verify whether the js file is the latest version and whether it has been modified. During the development and testing process, the front-end system needs to call this interface at startup to verify whether the locally introduced js file is the latest version and valid. Otherwise, the startup will fail.

[0152] Fig.12It is a flow chart of the front-end development provided by the embodiment of the present application. Step 801, the front end downloads the js file. When the front-end page is developed, it is necessary to download the js file of the specific business system from the parameter management system, and then introduce the specific input and output js files into the front-end system to develop a specific function. Step 802, verify the js file. When developing or testing, it is necessary to verify the js file (corresponding to the first script file in the above embodiment) when starting the front-end system, and verify the MD5 value of the js file and the js file in the parameter management system (corresponding to the second script file in the above embodiment). If the verification fails, the front-end system fails to start, and the front-end developer re-introduces the js file according to the returned error prompt and starts the front-end system again. Step 803, develop new functions, and obtain the input parameter field information corresponding to the new functions. When developing a new function, the input parameter field information will be obtained from the js file according to the back-end interface to be called by the new function. Step 804, dynamically render the page components required for the new interface according to the input parameter field information. Commonly used page components include input boxes, radio buttons, drop-down lists and other components, and custom components can also be used. The page components required for rendering the page are defined in the js file. Step 805, determine the field value. Enter the field value in the user input page and click the Save button, for example, the user enters the user ID and password and clicks Save. Step 806, request the backend service interface. Assemble the input parameter (corresponding to the first input parameter in the above embodiment) and the specific parameter value of the input parameter, obtain the interface call request, and then call the backend service interface based on the interface call request. Step 807, the backend performs input parameter verification. The backend verifies the number of fields and field names in the received input parameter based on the downloaded jar package. If the number of fields and / or field names of the input parameters in the jar package are different from the number of fields and / or field names in the received input parameter, the backend fails to verify the input parameter and displays the reason for the failure, otherwise the prompt operation is successful. Step 808, develop a list query function and obtain the input parameter field information corresponding to the list query function. Develop a list query function, and obtain the input parameter field information and output parameter field information from js according to the backend interface to be called by the function. Step 809, dynamically render the query conditions of the list query interface according to the input parameter field information. Step 810, dynamically render the list display field of the list query interface according to the output parameter field information. Step 811, dynamically render the list. When receiving the output parameter field value returned by the backend system, the front-end system verifies the number of fields and field names in the received output parameter based on the js file. If the number of fields and / or field names of the output parameters in the js file are different from the number of fields and / or field names in the received output parameters, the front-end verification of the output parameters fails and the reason for the failure is displayed. Otherwise, the output parameter field value will be dynamically rendered in the list display field.If a field returned by the backend has no return value (for example, there is neither field nor value), the words "No value returned from the backend" will be displayed directly in the position where the field is displayed in the list to prompt the backend developer to check whether the data returned by the interface is correct.

[0153] Fig.13 It is a flow chart of the back-end development provided by the embodiment of the present application. Step 901, the back-end downloads the jar package. When developing the back-end service, it is necessary to introduce the jar package of the input and output parameters. Step 902, verify the jar package. When developing or testing, it is necessary to verify whether the jar package (corresponding to the first software package in the above embodiment) is the latest version when starting the back-end system, and verify the MD5 value of the jar package and the jar package in the parameter management system (corresponding to the second software package in the above embodiment). If the verification fails, the back-end system fails to start. The back-end developer re-introduces the jar package according to the returned error prompt and starts the back-end system again. Step 903, write the back-end interface. Use the corresponding input and output parameter classes in the jar package to write a specific back-end http interface. Step 904, verify the input parameters in the interface call request. When receiving the parameters from the front-end interface call request, it is necessary to verify whether the input parameters in the interface call request and the input parameters in the back-end jar package are completely matched (that is, whether the fields are consistent). When the verification passes, execute step 905; when the verification fails, execute step 906. Step 905, perform the validity check of the input parameter value. The validity check is to check whether the input parameter field is required, whether it is a number, or the valid range of the field value. If the check fails, an error prompt will be returned to the front end, indicating that a field value check fails. If the check succeeds, execute step 907. Step 906, return an error prompt to the front end. Step 907, save the input parameter value to the storage medium. For example, save the input parameter value to a database.

[0154] The embodiment of the present application performs unified parameter design and file version control in the parameter management system, so that the front-end and back-end personnel cannot make arbitrary modifications, avoiding the problem of asynchronous development of the front-end and back-end caused by the inconsistency of the input and output parameters of a certain function, thereby improving the stability of the system. The embodiment of the present application can also detect the inconsistency of the js version or jar package version in advance through verification, thereby detecting the mismatch between the input and output parameters in advance. The embodiment of the present application can reuse some input and output parameters through the definition of common fields, achieve the unification of parameter fields, and improve development efficiency.

[0155] The following is a description of an exemplary structure of the parameter checking device 455 provided in the embodiment of the present application implemented as a software module. In some embodiments, Figure 2 As shown, the software modules stored in the parameter checking device 455 of the memory 450 may include:

[0156] The first verification module 4551 is used to perform a first verification on a first script file stored locally and a second script file in the parameter management system to obtain a first verification result; the input parameter determination module 4552 is used to determine the first input parameter from the first script file when the first verification result is passed, and generate an interface call request based on the first input parameter; the interface call module 4553 is used to send an interface call request to the second device, wherein the interface call request is used for the second device to perform a second verification on the first input parameter to obtain a second verification result, and when the second verification result is passed, output a first output parameter corresponding to the first input parameter; the parameter verification module 4554 is used to receive the first output parameter, and perform a third verification on the first output parameter based on the first script file to obtain a parameter verification result.

[0157] In some embodiments, the parameter verification module 4554 is also used to query a mapping table based on the first parameter type of the first output parameter, wherein the mapping table includes a correspondence between the parameter type and the level verification method; the level verification method corresponding to the first parameter type obtained by query is determined as the first level verification method of the first output parameter; based on the first script file, the first output parameter is level verified according to the first level verification method to obtain a parameter verification result.

[0158] In some embodiments, the level check corresponding to the first level check method includes quantity check, name check and field value check, and the first output parameter includes the first field and the first field value of the first field. The parameter check module 4554 is also used to determine the second output parameter corresponding to the first input parameter from the first script file, and perform quantity check on the quantity of the first field and the quantity of the second field included in the second output parameter; if the quantity check passes, perform name check on the name of the first field and the name of the second field; if the name check passes, perform field value check on the first field value based on the field value rule of the first field to obtain a parameter check result, wherein the field value rule is used to limit the type and range of the first field value.

[0159] In some embodiments, the parameter verification device also includes an anomaly detection module, which is used to extract features from the behavior data of the account corresponding to the first device to obtain behavior features; perform anomaly detection processing on the behavior features to obtain abnormal parameter values; when the abnormal parameter value is less than a first threshold, determine to execute an operation based on the first input parameter to generate an interface call request.

[0160] In some embodiments, the first input parameter includes a third field. The input parameter determination module 4552 is further used to determine a second field value of the third field; determine a fourth field from the third field, wherein the fourth field is the third field with an associated relationship; and generate an interface call request based on the third field and the second field value when the third field value of the fourth field satisfies a constraint condition.

[0161] In some embodiments, the first verification module 4551 is further used to perform hash processing on the first script file to obtain a first hash value; determine a second hash value of the second script file from the parameter management system; and compare the first hash value and the second hash value.

[0162] The embodiment of the present application provides a computer program product, which includes a computer program or a computer executable instruction, and the computer program or the computer executable instruction is stored in a computer-readable storage medium. The processor of the electronic device reads the computer executable instruction from the computer-readable storage medium, and the processor executes the computer executable instruction, so that the electronic device performs the parameter verification method described in the embodiment of the present application.

[0163] The present application embodiment provides a computer-readable storage medium, in which computer executable instructions or computer programs are stored. When the computer executable instructions or computer programs are executed by a processor, the processor will be caused to execute the parameter verification method provided by the present application embodiment, for example, Figure 3 The parameter verification method is shown.

[0164] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or may be various devices including one or any combination of the above memories.

[0165] In some embodiments, computer executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0166] As an example, computer-executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0167] As an example, computer executable instructions may be deployed to be executed on one electronic device, or on multiple electronic devices located at one site, or on multiple electronic devices distributed at multiple sites and interconnected by a communication network.

[0168] In summary, the embodiments of the present application can reduce the problems with interface corresponding functions caused by parameter mismatch during the front-end and back-end development process, thereby improving the development efficiency and collaboration of the front-end and back-end.

[0169] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A parameter verification method, characterized in that: Applied to a first device, the method includes: Performing a first verification on a first script file stored locally and a second script file in the parameter management system to obtain a first verification result; If the first verification result is passed, determining a first input parameter from the first script file, and generating an interface call request based on the first input parameter; Sending the interface call request to the second device, wherein the interface call request is used for the second device to perform a second check on the first input parameter to obtain a second check result, and if the second check result is passed, outputting a first output parameter corresponding to the first input parameter; The first output parameter is received, and a third check is performed on the first output parameter based on the first script file to obtain a parameter check result.

2. The method according to claim 1, characterized in that The performing a third check on the first output parameter based on the first script file to obtain a parameter check result includes: Based on the first parameter type of the first output parameter, querying a mapping table, wherein the mapping table includes a correspondence between parameter types and level verification methods; Determine the queried level verification method corresponding to the first parameter type as the first level verification method of the first output parameter; Based on the first script file, the first output parameter is level-checked according to the first level-checking method to obtain a parameter check result.

3. The method according to claim 2, characterized in that The level verification corresponding to the first level verification method includes quantity verification, name verification and field value verification, and the first output parameter includes a first field and a first field value; The step of performing level verification on the first output parameter according to the first level verification method based on the first script file to obtain a parameter verification result includes: Determine a second output parameter corresponding to the first input parameter from the first script file, and perform the quantity check on the number of the first fields and the number of second fields included in the second output parameter; If the quantity check passes, performing the name check on the name of the first field and the name of the second field; When the name check passes, the field value check is performed on the first field value based on the field value rule of the first field to obtain a parameter check result, wherein the field value rule is used to limit the type and range of the first field value.

4. The method according to any one of claims 1 to 3, characterized in that: Before generating an interface call request based on the first input parameter, the method further includes: Extracting features from the behavior data of the account corresponding to the first device to obtain behavior features; Performing anomaly detection processing on the behavior characteristics to obtain an abnormal parameter value; When the abnormal parameter value is less than a first threshold, it is determined to execute an operation of generating an interface call request based on the first input parameter.

5. The method according to claim 1, characterized in that The first input parameter includes a third field; and the generating an interface call request based on the first input parameter includes: determining a second field value of the third field; Determine a fourth field from the third field, wherein the fourth field is the third field having an associated relationship; In the case where the constraint condition is satisfied between the third field values ​​of the fourth field, an interface call request is generated based on the third field and the second field value.

6. The method according to claim 1, characterized in that The first verification of the locally stored first script file and the second script file in the parameter management system includes: Performing hash processing on the first script file to obtain a first hash value; Determining a second hash value of the second script file from the parameter management system; The first Hash value and the second Hash value are compared.

7. A parameter verification method, characterized in that: Applied to the second device, the method includes: Performing a fourth verification on the locally stored first software package and the second software package in the parameter management system to obtain a fourth verification result; If the fourth verification result is passed, performing a second verification on the first input parameter in the received interface call request based on the first software package to obtain a second verification result; If the second verification result is passed, determining a first output parameter corresponding to the first input parameter from the first software package; The first output parameter is sent to the first device, wherein the first output parameter is used for the first device to perform a third verification to obtain a parameter verification result.

8. The method according to claim 7, characterized in that The interface call request includes a first timestamp; before performing a second check on the first input parameter in the received interface call request based on the first software package, the method further includes: Determine a second timestamp of receiving the interface call request; When the difference between the second timestamp and the first timestamp is greater than or equal to a preset threshold, sending a parameter verification result of verification failure to the first device; When the difference is smaller than the preset threshold, it is determined to perform a second check on the first input parameter in the interface call request based on the first software package.

9. A parameter verification device, characterized in that: The device comprises: A first verification module, used to perform a first verification on a first script file stored locally and a second script file in the parameter management system to obtain a first verification result; An input parameter determination module, configured to determine a first input parameter from the first script file when the first verification result is passed, and generate an interface call request based on the first input parameter; an interface calling module, configured to send the interface calling request to the second device, wherein the interface calling request is used for the second device to perform a second check on the first input parameter to obtain a second check result, and output a first output parameter corresponding to the first input parameter when the second check result is passed; A parameter verification module is used to receive the first output parameter and perform a third verification on the first output parameter based on the first script file to obtain a parameter verification result.

10. An electronic device, characterized in that: The electronic device comprises: A memory for storing computer executable instructions or computer programs; A processor, used to implement the parameter verification method described in any one of claims 1 to 8 when executing the computer executable instructions or computer programs stored in the memory.

11. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the parameter verification method according to any one of claims 1 to 8 is implemented.

12. A computer program product comprising computer executable instructions or a computer program, characterized in that: When the computer executable instructions or computer program are executed by a processor, the parameter verification method according to any one of claims 1 to 8 is implemented.

Images