A JSON verification-based service calling method and device

Abstract

The application discloses a business calling method and device based on JSON verification, and the method comprises the following steps: when a user's business access request is acquired, a business verification code is extracted from a preset cache according to a business type corresponding to the business access request; the business access request is verified according to a verification field in the business verification code in the preset cache; if the verification is passed, a corresponding business processing engine is called to execute a business operation corresponding to the business access request. The application can edit multiple business verification codes in a JSON format in advance, and then store the multiple business verification codes in the cache, so that the memory occupation is reduced, the capacity of the background is released, the business verification code is extracted from the cache when the user calls the business, and the access request is verified by using the business verification code in the cache, so that the verification process is simplified, the verification time is shortened, and the processing efficiency of the verification is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of service invocation, and in particular to a service invocation method and device based on JSON verification. BACKGROUND

[0002] With the development of application terminals and application systems, their service functions are gradually increasing. Each user can call different service functions of different services by interacting with the service system.

[0003] In order to regulate and orderly execute each service function, the currently commonly used calling method is that the service system, after receiving the user calling request or the calling metadata, first verifies the metadata (such as non-empty verification or combined field verification), and only when the verification passes, the corresponding service function can be called.

[0004] However, the currently commonly used method has the following technical problems: the non-empty verification or combined field verification code is stored in the background, and when the service function increases, the number of stored verification codes also increases, occupying the system memory; and each time the verification is performed, the verification code needs to be taken out from the background memory and then verified by using the verification code, and the whole process is time-consuming and inefficient. SUMMARY

[0005] The present application provides a service invocation method and device based on JSON verification, which can pre-edit the fields of each verification code in JSON format and store each verification code field in the cache. When a user needs to call a service, the verification code is directly called from the cache for verification, and only when the verification passes, the service operation is performed. On the one hand, the verification code can reduce the occupation of memory and release the capacity of the background, and on the other hand, the operation process of calling the verification code from the cache is simple and time-saving, effectively improving the processing efficiency of verification.

[0006] The first aspect of the embodiment of the present application provides a service invocation method based on JSON verification, which comprises:

[0007] When a user's service access request is obtained, a service verification code corresponding to the service type of the service access request is extracted from a preset cache, and the preset cache stores a plurality of pre-edited service verification codes in JSON format;

[0008] The service access request is verified according to the verification field in the service verification code in the preset cache;

[0009] If the verification passes, a corresponding service processing engine is called to execute the service operation corresponding to the service access request.

[0010] In a possible implementation manner of the first aspect, before the step of obtaining the service access request of the user, the method further includes:

[0011] obtaining a plurality of service interfaces, determining metadata constraint information corresponding to each of the service interfaces, editing a field corresponding to each of the service interfaces based on the metadata constraint information, and obtaining a plurality of initial fields, wherein the metadata constraint information includes an input parameter, an output parameter and interface definition;

[0012] storing the plurality of initial fields in a cache, and performing a cleaning operation on each of the initial fields to obtain a plurality of cleaned fields;

[0013] performing first encryption on the plurality of cleaned fields by using a preset first encryption algorithm, transmitting the plurality of cleaned fields after the first encryption to a preset central server for signature, and obtaining a plurality of signature data;

[0014] performing second encryption on the plurality of signature data by using a preset second encryption algorithm, obtaining a plurality of service verification codes, and storing the plurality of service verification codes in a preset cache.

[0015] In a possible implementation manner of the first aspect, the access verification of the service access request in the preset cache according to the verification field in the service verification code includes:

[0016] decrypting and parsing the service verification code by using a decryption algorithm to obtain a verification field;

[0017] determining whether the data type of the verification field is the same as the data type of the service access request;

[0018] if the data type of the verification field is the same as the data type of the service access request, determining that the access verification is passed;

[0019] if the data type of the verification field is not the same as the data type of the service access request, determining that the access verification is not passed.

[0020] In a possible implementation manner of the first aspect, the extraction of the service verification code from the preset cache according to the service type corresponding to the service access request includes:

[0021] obtaining a service type corresponding to the service access request, searching for a metadata attribute of an API node corresponding to the service based on the service type, and

[0022] extracting the service verification code from the preset cache according to the metadata attribute.

[0023] In a possible implementation manner of the first aspect, the calling the corresponding business processing engine to perform the business operation corresponding to the business access request comprises:

[0024] obtaining a condition parameter in a JSON format from the cache, the condition parameter comprising an API retrieval field and a sorting field;

[0025] encapsulating the condition parameter into an SQL instruction, calling the corresponding business processing engine to transmit the SQL instruction to a preset library table engine, so that the preset library table engine performs a business operation according to metadata information and a condition constraint of the SQL instruction and returns business processing data.

[0026] The second aspect of the embodiment of the application provides a business calling device based on JSON verification, the device comprising:

[0027] an extraction module configured to extract a business verification code from a preset cache according to a business type corresponding to a business access request of a user when the business access request is obtained, the preset cache storing a plurality of pre-edited business verification codes in a JSON format;

[0028] a verification module configured to perform access verification on the business access request according to a verification field in the business verification code in the preset cache;

[0029] an execution module configured to call a corresponding business processing engine to perform a business operation corresponding to the business access request if the access verification is passed.

[0030] In a possible implementation manner of the second aspect, the device further comprises:

[0031] an obtaining module configured to obtain a plurality of business interfaces and determine metadata constraint information corresponding to each of the business interfaces, edit a field corresponding to each of the business interfaces based on the metadata constraint information, and obtain a plurality of initial fields, the metadata constraint information comprising an input parameter, an output parameter and an interface definition;

[0032] a storage and cleaning module configured to store the plurality of initial fields in a cache and perform a cleaning operation on each of the initial fields to obtain a plurality of cleaned fields;

[0033] a first encryption module configured to perform a first encryption on the plurality of cleaned fields by using a preset first encryption algorithm, and transmit the plurality of cleaned fields after the first encryption to a preset central server for signature to obtain a plurality of signature data;

[0034] A secondary encryption module is configured to encrypt the plurality of signatures using a preset second encryption algorithm to obtain a plurality of service verification codes, and store the plurality of service verification codes in a preset cache.

[0035] In a possible implementation of the second aspect, the verification module is further configured to:

[0036] decrypt and parse the service verification code by using a decryption algorithm to obtain a verification field;

[0037] determine whether the data type of the verification field is the same as the data type of the service access request;

[0038] if the data type of the verification field is the same as the data type of the service access request, determine that the access verification is passed;

[0039] if the data type of the verification field is not the same as the data type of the service access request, determine that the access verification is not passed.

[0040] In a possible implementation of the second aspect, the extraction module is further configured to:

[0041] obtain a service type corresponding to the service access request, and find metadata attributes of an API node corresponding to the service based on the service type;

[0042] extract a service verification code from a preset cache according to the metadata attributes.

[0043] In a possible implementation of the second aspect, the execution module is further configured to:

[0044] obtain a conditional parameter in a JSON format from the cache, wherein the conditional parameter includes an API retrieval field and a sorting field;

[0045] encapsulate the conditional parameter into an SQL instruction, call a corresponding service processing engine to transmit the SQL instruction to a preset library table engine, so that the preset library table engine performs a service operation according to metadata information and a conditional constraint of the SQL instruction and returns service processing data.

[0046] Compared with the prior art, the business calling method and device based on JSON verification provided by the embodiment of the present application have the beneficial effects that: the present application can pre-edit a plurality of business verification codes in the JSON format, and then store the plurality of business verification codes in the cache, so as to reduce the memory occupied by the verification codes and release the capacity of the background; when a user calls a business, the business verification code is extracted from the cache and used to verify the access request in the cache, so that the whole verification process is simplified, the time consumption of verification is shortened, the processing efficiency of verification is effectively improved, and in addition, the encryption storage method used in the present application realizes the digital signature and verification operation, and improves the security and confidentiality of the metadata. BRIEF DESCRIPTION OF DRAWINGS

[0047] Figure 1 is a flow diagram of a business calling method based on JSON verification provided by an embodiment of the present application;

[0048] Figure 2 is an operation flow diagram of generating a business verification code provided by an embodiment of the present application;

[0049] Figure 3 is an operation flow diagram of access verification provided by an embodiment of the present application;

[0050] Figure 4 is an operation flow diagram of a business calling method based on JSON verification provided by an embodiment of the present application;

[0051] Figure 5 is a structural diagram of a business calling device based on JSON verification provided by an embodiment of the present application. DETAILED DESCRIPTION

[0052] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0053] With the development of application terminals and application systems, the business functions thereof are gradually increased. Each user can call different business functions by interacting with the business system.

[0054] In order to standardize and orderly execute each business function, the currently commonly used calling method is that the business system first verifies the metadata (for example, non-empty verification or verification of combined fields) after receiving the user calling request or the metadata of the calling, and only when the verification passes, the corresponding business function can be called.

[0055] However, the current method has the following technical problems: the non-empty check or the check code of the combination field is stored in the background, when the business function increases, the number of stored check codes also increases, occupying the system memory; and each time the check is performed, the verification code needs to be taken out from the background memory, and then the verification code is used for verification, the whole process is time-consuming and low in efficiency.

[0056] To solve the above problems, the following will introduce and illustrate a JSON verification-based business calling method provided by the embodiments of the application through the following specific embodiments.

[0057] Referring to Figure 1 , a flowchart of a JSON verification-based business calling method provided by an embodiment of the application is shown.

[0058] For example, the JSON verification-based business calling method can include the following steps.

[0059] S11, when a user's business access request is obtained, a business verification code corresponding to the business type of the business access request is extracted from a preset cache, and the preset cache stores a plurality of pre-edited JSON format business verification codes.

[0060] In an embodiment, a user can pre-edit a plurality of business verification codes, and each business verification code can correspond to a business access or calling request. Each business verification code is stored in the cache. When a user accesses a business or calls a business, the business verification code can be directly extracted from the cache, and the user is verified, the permission is checked, or the type of the business to be called by the user is determined according to the business verification code.

[0061] In an embodiment, each business operation can correspond to a business interface, and each business interface can correspond to an API node information, so that the corresponding verification code can be found according to the API node information for checking.

[0062] For example, step S11 can include the following sub-steps.

[0063] S111, the business type corresponding to the business access request is obtained, and the metadata attribute of the API node corresponding to the business is found based on the business type.

[0064] S112, the business verification code is extracted from the preset cache according to the metadata attribute.

[0065] Specifically, the service access request of the user can be forwarded to a preset metadata verification engine, metadata attributes of the service access request can be extracted by the metadata verification engine, and the metadata attributes can be API nodes or API codes of the request. Then, the corresponding service verification code is obtained in the cache manager according to the metadata attributes. In an embodiment, the service verification code can be a JSON segment.

[0066] To ensure the privacy of each service verification code, before step S11, the method can further include the following steps:

[0067] S21, a plurality of service interfaces are obtained, and metadata constraint information corresponding to each service interface is determined, fields corresponding to each service interface are edited based on the metadata constraint information, and a plurality of initial fields are obtained, and the metadata constraint information includes: input parameters, output parameters, and interface definitions.

[0068] Each service interface corresponds to a callable service function. Each service interface has its corresponding metadata constraint information, and the metadata constraint information is used to constrain or limit the interface. In an embodiment, the metadata constraint information can include: input parameters (which can be access parameters in particular), output parameters (which can be output parameters in particular), interface definitions (interface numbers or custom types), and the like. The metadata constraint information can be used to verify the input parameter field name, field type, field size, and output parameter field name, output parameter field type, and the like of the current access interface.

[0069] After the metadata constraint information is determined, the fields corresponding to each service interface are edited according to the metadata constraint information, which can be used as the code of the service interface, thereby obtaining a plurality of initial fields.

[0070] In an embodiment, the initial fields edited according to the metadata constraint information can be edited according to the definition of the following table.

[0071]

[0072] It should be noted that the defined JSON format field has the following characteristics:

[0073] First, the code in the JSON configuration is the code of interface access, through which the specific interface to be accessed can be located, and the access mode and the description of the interface can be defined through isAsync, desc, requestAgreement, name, resourcePath, and the like.

[0074] Second, the reqSchema object in the JSON configuration is the constraint of the request input parameter, and the access control of the interface depends on whether the input parameter of the interface meets the condition defined by reqSchema. If not, access will be denied.

[0075] Third, the resSchema object in the JSON configuration is the constraint of the request output parameter, and the return format of the interface depends on the definition of resSchema. If not, the result parsing will be wrong.

[0076] Fourth, other fields are defined as properties of the interface, such as_search, _sort, etc.

[0077] Among them, the execution of an interface is divided into three stages: REQUEST (request), EXECUTE (execution), and RESPONSE (response). In JSONScheme, the impact of each stage of the interface is as follows:

[0078] REQUEST stage: subject to the above first and second points, it must meet these two points to match through;

[0079] EXECUTE stage: this stage is the execution stage of the interface, and the metadata definition of the interface execution process mainly depends on the configuration of the fourth point, but is not affected by the REQUEST stage;

[0080] RESPONSE stage: subject to the above third point, it must meet the format defined by this point to determine the interface data format returned, but it does not affect the interface REQUEST, mainly the assembly of the EXECUTE stage execution result, forming the output parameter format defined in the third point above.

[0081] S22, store a plurality of initial fields in the cache, and perform cleaning operations on each initial field to obtain a plurality of cleaned fields.

[0082] Cleaning each initial field can complete or delete each initial field so that each initial field is the same length or the same format.

[0083] S23, using a preset first encryption algorithm to encrypt the plurality of cleaned fields for the first time, and transmitting the plurality of cleaned fields encrypted for the first time to a preset central server for signing to obtain a plurality of signature data.

[0084] In an embodiment, the preset first encryption algorithm can be a HASH encryption algorithm.

[0085] After encrypting each data, each data can be transmitted to the preset central server in sequence, and the central server adds a signature to each data to obtain a plurality of signature data.

[0086] S24, a second encryption algorithm is used to encrypt the plurality of signatures to obtain a plurality of service verification codes, and the plurality of service verification codes are stored in a preset cache.

[0087] In an embodiment, the preset second encryption algorithm can be an asymmetric ECC encryption algorithm.

[0088] Through twice encryption, it can be ensured that each service verification code is unique and difficult to be tampered with, and the security and privacy of data can be ensured.

[0089] Referring to Figure 2 , an operation flowchart for generating a service verification code provided by an embodiment of the application is shown.

[0090] In a specific implementation, the initial field can be cleaned first, and then encrypted by a HASH encryption algorithm; after the encryption is completed, the data can be transmitted to the center server to add a signature to each data; finally, the signature data is encrypted twice by using an asymmetric ECC encryption algorithm to obtain a service verification code, and each service verification code is stored in the cache, and when a user accesses, it is extracted from the cache and verified.

[0091] S12, according to the check field in the service verification code, the service access request is verified in the preset cache.

[0092] After the service verification code is extracted, the check field of the user check in the service verification code can be directly used in the cache to verify the service access request.

[0093] If the access is passed, the service is called, otherwise the service is not called.

[0094] In an optional embodiment, step S12 can include the following sub-steps:

[0095] S121, the service verification code is decrypted and parsed by using a decryption algorithm to obtain a check field.

[0096] Since each service verification code is encrypted, the service verification code can be decrypted first, then the decrypted field is parsed to extract the field for checking to obtain the check field.

[0097] In an optional embodiment, the check field can correspond to the above-mentioned JSON segment.

[0098] S122, determine whether the data type of the check field and the data type of the service access request are the same.

[0099] S123, if the data type of the check field is same as the data type of the service access request, it is determined that the access verification is passed.

[0100] S124, if the data type of the check field is not same as the data type of the service access request, it is determined that the access verification is not passed.

[0101] Referring to Figure 3 , the operation flow chart of the access verification provided by an embodiment of the present application is shown.

[0102] In actual operation, it can be judged whether the data type of the check field is same as the data type of the service access request. If yes, it is determined that the user can legally invoke the service, and the access verification is passed; otherwise, if no, it is determined that the user cannot legally invoke the service, and the access verification is not passed.

[0103] It should be noted that in the verification, the complete service interface request specification can be viewed from the service access request transmitted by the client, and the resSchema in the value stores the metadata field information of the service interface access, such as field name, field size, field type, field default value, etc.; the properties field in the value stores all metadata attributes of the API node; the requestAgreement in the value is the request mode of the service interface, and the resSchema in the value stores the response information after the service API access, including response field, response field type, etc.

[0104] The above various information can be compared with the service verification code, and if same, the verification is passed, and if not same, the verification is not passed.

[0105] S13, if the access verification is passed, the corresponding service processing engine is invoked to execute the service operation corresponding to the service access request.

[0106] If the access verification is passed, the service processing engine corresponding to the access service can be directly invoked to execute the service operation corresponding to the service access request.

[0107] In one of the embodiments, the step S13 can include the following sub-steps:

[0108] S131, the condition parameters in JSON format are obtained from the cache, and the condition parameters include API retrieval field and sorting field.

[0109] S132, the condition parameters are encapsulated into SQL instructions, the corresponding service processing engine is invoked to transmit the SQL instructions to the preset library table engine, so that the preset library table engine executes the service operation according to the metadata information and condition constraints of the SQL instructions and returns the service processing data.

[0110] In actual operation, the condition parameter required for executing the service can also be extracted from the cache, and the condition parameter can also be a parameter required for executing the service and edited in advance by the user in the JSON format.

[0111] The condition parameter can include an API retrieval field and a sorting field.

[0112] Then, the condition parameter can be encapsulated into an SQL instruction, and the SQL instruction is transmitted to a corresponding library table engine through the service processing engine, so that the library table engine converts into an SQL instruction and calls a database plug-in to execute the SQL according to metadata information and a condition constraint of the SQL instruction; finally, the library table engine returns a result of the query to the service processing engine, and the service processing engine assembles a return structure according to a resScheme definition of the JSON and returns to the user.

[0113] Referring to Figure 4 FIG. 1 shows an operation flowchart of a service calling method based on JSON verification according to an embodiment of the present application.

[0114] Specifically, the service calling method can include the following processes.

[0115] 1. A user initiates access to a service API;

[0116] 2. The user accesses a specified metadata verification engine, and the metadata verification engine acquires a corresponding JSON segment from an API code area cache manager;

[0117] 3. The JSON is decrypted through a decryption algorithm, and a reqScheme field in the JSON is parsed to obtain request field information;

[0118] 4. The parameter value in the API is matched through encoding, field size, whether it is required to be filled, and field type defined by the reqScheme field;

[0119] 5. A matching result is obtained, such as returning true, calling a service processing engine to process API service logic; otherwise, an exception information is returned, and the process ends.

[0120] 6. After the above metadata request verification, the metadata processing engine initiates an instruction to notify the service processing engine, and the service processing engine obtains condition parameters such as an API retrieval field and a sorting field from the JSON and encapsulates them into an SQLDTO;

[0121] 7. The service processing engine returns the SQLDTO to a library table engine, and the library table engine converts into an sql statement and calls a database plug-in to execute the sql according to metadata information and a condition constraint of the SQLDTO;

[0122] 8. The library table engine returns the result of the query to the business processing engine, which assembles a return structure according to the resScheme definition of the JSON and returns it to the user.

[0123] In the embodiment, the application provides a business calling method based on JSON verification, which has the beneficial effects that: the application can pre-edit a plurality of business verification codes in the JSON format, and then store the plurality of business verification codes in the cache, so as to reduce the memory occupied by the verification codes, release the capacity of the background, when a user calls a business, extract the business verification code from the cache and verify the access request by using the business verification code in the cache, simplify the whole verification process, shorten the time consumption of verification, effectively improve the processing efficiency of verification, in addition, the encryption storage method used in the application realizes the digital signature and verification operation, improves the security and confidentiality of the metadata.

[0124] The application further provides a business calling device based on JSON verification, which is described with reference to Figure 5 , which shows a structure schematic diagram of a business calling device based on JSON verification provided by an embodiment of the application.

[0125] For example, the business calling device based on JSON verification can include:

[0126] The extraction module 501 is configured to extract a business verification code from a preset cache according to a business type corresponding to a business access request of a user when the business access request is acquired, and the preset cache stores a plurality of pre-edited business verification codes in the JSON format.

[0127] The verification module 502 is configured to perform access verification on the business access request according to a verification field in the business verification code in the preset cache.

[0128] The execution module 503 is configured to call a corresponding business processing engine to perform a business operation corresponding to the business access request if the access verification is passed.

[0129] Optionally, the device further includes:

[0130] The acquisition module is configured to acquire a plurality of business interfaces, determine metadata constraint information corresponding to each business interface, edit a field corresponding to each business interface based on the metadata constraint information, and obtain a plurality of initial fields, wherein the metadata constraint information includes: input parameters, output parameters, and interface definition.

[0131] The storage and cleaning module is configured to store the plurality of initial fields in the cache, and perform a cleaning operation on each initial field to obtain a plurality of cleaned fields.

[0132] A first encryption module is configured to encrypt the plurality of cleaning fields by using a preset first encryption algorithm, and transmit the plurality of cleaning fields after the first encryption to a preset central server for signature, to obtain a plurality of signature data;

[0133] A second encryption module is configured to encrypt the plurality of signature data by using a preset second encryption algorithm, to obtain a plurality of service verification codes, and store the plurality of service verification codes in a preset cache.

[0134] Optionally, the verification module is further configured to:

[0135] decrypt and parse the service verification code by using a decryption algorithm to obtain a verification field;

[0136] determine whether the data type of the verification field is the same as the data type of the service access request;

[0137] if the data type of the verification field is the same as the data type of the service access request, it is determined that the access verification is passed;

[0138] if the data type of the verification field is not the same as the data type of the service access request, it is determined that the access verification is not passed.

[0139] Optionally, the extraction module is further configured to:

[0140] obtain a service type corresponding to the service access request, and find a metadata attribute of an API node corresponding to the service based on the service type;

[0141] extract a service verification code from the preset cache according to the metadata attribute.

[0142] Optionally, the execution module is further configured to:

[0143] obtain a conditional parameter in a JSON format from the cache, the conditional parameter including an API retrieval field and a sorting field;

[0144] encapsulate the conditional parameter into a SQL instruction, call a corresponding service processing engine to transmit the SQL instruction to a preset library table engine, so that the preset library table engine performs a service operation according to metadata information and a conditional constraint of the SQL instruction and returns service processing data.

[0145] Those skilled in the art can clearly understand the specific working process of the device described above for the convenience of description and brevity, which can refer to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0146] Further, the embodiment of the present application further provides an electronic device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to realize the JSON verification based service calling method as described in the above embodiment.

[0147] Further, the embodiment of the present application further provides a computer readable storage medium, wherein the computer readable storage medium stores a computer executable program, and the computer executable program is used to make the computer execute the JSON verification based service calling method as described in the above embodiment.

[0148] The above is the preferred embodiment of the present application, it should be noted that, for those skilled in the art, without departing from the principles of the present application, can make a number of improvements and refinements, these improvements and refinements are also considered to be the protection scope of the present application.

Claims

1. A method for business invocation based on JSON validation, characterized in that, The method comprises: When a user's service access request is acquired, a service verification code is extracted from a preset cache according to a service type corresponding to the service access request, the preset cache storing a plurality of pre-edited service verification codes in JSON format; In the preset cache, the service access request is verified according to a verification field in the service verification code; If the verification is passed, a corresponding service processing engine is called to execute a service operation corresponding to the service access request; Before the step of acquiring the user's service access request, the method further comprises: A plurality of service interfaces are acquired, and metadata constraint information corresponding to each service interface is determined, fields corresponding to each service interface are edited based on the metadata constraint information, a plurality of initial fields are obtained, and the metadata constraint information comprises: input parameters, output parameters, and interface definition; The plurality of initial fields are stored in a cache, and each initial field is subjected to a cleaning operation to obtain a plurality of cleaned fields; The plurality of cleaned fields are subjected to a first encryption by using a preset first encryption algorithm, and the plurality of cleaned fields subjected to the first encryption are transmitted to a preset central server for signature to obtain a plurality of signature data; The plurality of signature data are subjected to a second encryption by using a preset second encryption algorithm to obtain a plurality of service verification codes, and the plurality of service verification codes are stored in the preset cache.

2. The JSON validation based business invocation method according to claim 1, wherein, The verification of the service access request in the preset cache according to the verification field in the service verification code comprises: The service verification code is decrypted and parsed by using a decryption algorithm to obtain a verification field; It is determined whether the data type of the verification field is the same as the data type of the service access request; If the data type of the verification field is the same as the data type of the service access request, it is determined that the verification is passed; If the data type of the verification field is not the same as the data type of the service access request, it is determined that the verification is not passed.

3. The JSON validation based business invocation method as claimed in claim 1, wherein, The extraction of the service verification code from the preset cache according to the service type corresponding to the service access request comprises: The service type corresponding to the service access request is acquired, and the metadata attribute of the API node corresponding to the service is found based on the service type; The service verification code is extracted from the preset cache according to the metadata attribute.

4. The JSON validation based business invocation method as claimed in claim 1, wherein, The calling of the corresponding service processing engine to execute the service operation corresponding to the service access request comprises: A condition parameter in JSON format is acquired from the cache, and the condition parameter comprises: an API retrieval field and a sorting field; The condition parameter is encapsulated into an SQL instruction, the corresponding service processing engine is called to transmit the SQL instruction to a preset library table engine, so that the preset library table engine executes a service operation according to the metadata information and the condition constraint of the SQL instruction and returns service processing data.

5. A JSON validation based service invocation apparatus, characterized by, The device comprises: An extraction module is configured to extract a service verification code from a preset cache according to a service type corresponding to a service access request when the service access request of a user is acquired, the preset cache storing a plurality of pre-edited service verification codes in JSON format; The verification module is configured to perform access verification on the service access request according to a verification field in the service verification code in a preset cache. The execution module is configured to, if the access verification is passed, invoke a corresponding service processing engine to perform a service operation corresponding to the service access request. The device further comprises: The acquisition module is configured to acquire a plurality of service interfaces, determine metadata constraint information corresponding to each service interface, edit a field corresponding to each service interface based on the metadata constraint information, and obtain a plurality of initial fields, wherein the metadata constraint information includes input parameters, output parameters, and interface definition. The storage and cleaning module is configured to store the plurality of initial fields in a cache, and perform a cleaning operation on each initial field to obtain a plurality of cleaned fields. The first encryption module is configured to perform a first encryption on the plurality of cleaned fields by using a preset first encryption algorithm, and transmit the plurality of cleaned fields after the first encryption to a preset central server for signature to obtain a plurality of signature data. The second encryption module is configured to perform a second encryption on the plurality of signature data by using a preset second encryption algorithm to obtain service verification codes, and store the plurality of service verification codes in a preset cache.

6. The JSON validation based business invocation apparatus according to claim 5, wherein, The verification module is further configured to: decrypt and parse the service verification code by using a decryption algorithm to obtain a verification field; determine whether the data type of the verification field is the same as the data type of the service access request; if the data type of the verification field is the same as the data type of the service access request, determine that the access verification is passed; if the data type of the verification field is not the same as the data type of the service access request, determine that the access verification is not passed.

7. The JSON validation based business invocation apparatus as claimed in claim 5, wherein, The extraction module is further configured to: acquire a service type corresponding to the service access request, and find a metadata attribute of an API node corresponding to the service based on the service type; extract a service verification code from a preset cache according to the metadata attribute.

8. The JSON validation based business invocation apparatus as claimed in claim 5, wherein, The execution module is further configured to: acquire a condition parameter in a JSON format from the cache, wherein the condition parameter includes an API retrieval field and a sorting field; encapsulate the condition parameter into an SQL instruction, invoke a corresponding service processing engine to transmit the SQL instruction to a preset library table engine, so that the preset library table engine performs a service operation according to metadata information and condition constraints of the SQL instruction and returns service processing data.

Images