A front-end request code generation method and device, and a readable storage medium

Abstract

The application provides a front-end request code generation method, device and readable storage medium. The method comprises the following steps: obtaining swagger data in a swagger document; generating target parameters required by a front-end request code according to key information in the swagger data; and generating the front-end request code according to a preset code template of the front-end request and the target parameters. The method, device and readable storage medium can solve the problems that the front-end request code is developed and written manually in the prior art, which is time-consuming and laborious, and is prone to errors.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus and readable storage medium for generating front-end request code. Background Technology

[0002] According to project requirements, the front-end request code needs to be developed and written based on the Swagger documentation provided by the back-end interface. When the front-end developer writes the axios request code, they write the front-end JS request code based on some key information provided in the Swagger documentation. However, manually developing and writing the front-end request code is time-consuming, laborious, and prone to errors. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to address the above-mentioned shortcomings of the prior art by providing a front-end request code generation method, apparatus and readable storage medium, so as to at least solve the problem that manual development and writing of front-end request code in the prior art is time-consuming, laborious and prone to errors.

[0004] In a first aspect, the present invention provides a method for generating front-end request code, wherein the method...

[0005] The law includes:

[0006] Retrieve Swagger data from the Swagger documentation;

[0007] Generate the target parameters required for the front-end request code based on the key information in the Swagger data;

[0008] The front-end request code is generated based on the preset front-end request code template and the target parameters.

[0009] Furthermore, obtaining the Swagger data from the Swagger document specifically includes:

[0010] Receive the address of the Swagger document;

[0011] Since the address of the Swagger document is a network address, the Swagger data is obtained from the network address using the http module of node.js;

[0012] In response to the fact that the address of the Swagger document is a local address, the Swagger data is retrieved from the local address.

[0013] Furthermore, the target parameters include description information, prefix information, method information, and definition information. The method information includes at least one method object, and each method object includes a request address, request type, request description, request method name, and request parameters. The step of generating the target parameters required for the front-end request code based on the key information in the Swagger data specifically includes:

[0014] The description information required to generate the front-end request code is generated based on the description information in the Swagger data;

[0015] Generate the prefix information required for the front-end request code based on the domain information in the Swagger data;

[0016] Based on the method information in the Swagger data, generate the request address, request type, request description, and request parameters for each method object required to generate the front-end request code;

[0017] Based on the method information in the swagger data or each of the request addresses, generate the request method name in each method object required to generate the front-end request code;

[0018] The definition information required to generate the front-end request code is generated based on the definition information in the Swagger data.

[0019] Furthermore, the step of generating the prefix information required for the front-end request code based on the domain information in the Swagger data specifically includes:

[0020] Determine whether the domain information in the Swagger data contains the Schemes field, the host field, and the basePath field;

[0021] In response to the presence of the Schemes, host, and basePath fields in the domain information of the swagger data, the Schemes, host, and basePath fields are concatenated according to a preset concatenation rule to obtain the prefix information.

[0022] Furthermore, the step of generating the request method name in each method object required for the front-end request code based on the method information in the swagger data or each request address specifically includes:

[0023] For each method object, determine whether the operation identifier (operationId) of the method object exists in the method information of the swagger data;

[0024] In response to the existence of the operationId of the method object in the method information of the swagger data, special characters and spaces in the operationId are removed using regular expressions, the split method, and the join method to obtain the request method name in the method object;

[0025] If the operationId of the method object is not found in the method information of the swagger data, the request method name of the method object is generated based on the request address in the method object.

[0026] Further, generating the request method name in the method object based on the request address in the method object specifically includes:

[0027] The request address is split;

[0028] Use the transform method in lodash to determine whether there are code block separators in the segmented request address;

[0029] If a code block separator exists in the segmented request address, then the code block separator will be replaced.

[0030] The camelCase method in lodash is used to process the replaced request address into camelCase;

[0031] The request method name is obtained from the request address after processing with camelCase.

[0032] Furthermore, after generating the request address, request type, request description, and request parameters for each method object required for the front-end request code based on the method information in the Swagger data, the method further includes:

[0033] The request format of the request parameters in each of the method objects is specially identified and recorded.

[0034] Further, generating the front-end request code based on the preset front-end request code template and the target parameters specifically includes:

[0035] Register the code template;

[0036] Based on the target parameters and each recorded unique identifier, the registered code template is assigned a value to obtain the front-end request code.

[0037] In a second aspect, the present invention provides a front-end request code generation apparatus, comprising:

[0038] The retrieval module is used to retrieve Swagger data from the Swagger documentation.

[0039] The first generation module, connected to the acquisition module, is used to generate the target parameters required for the front-end request code based on the key information in the swagger data.

[0040] The second generation module, connected to the first generation module, is used to generate the front-end request code based on a preset front-end request code template and the target parameters.

[0041] Thirdly, the present invention provides a front-end request code generation apparatus, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to implement the front-end request code generation method described in the first aspect above.

[0042] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the front-end request code generation method described in the first aspect.

[0043] The present invention provides a front-end request code generation method, apparatus, and readable storage medium. First, it acquires Swagger data from a Swagger document; then, it generates target parameters required for the front-end request code based on key information in the Swagger data; finally, it generates the front-end request code based on a preset front-end request code template and the target parameters. This invention, through observation and analysis of mainstream Swagger document structures, extracts key information from the Swagger data, generates target parameters required for the front-end request code based on this key information, and uses the target parameters and a preset front-end request code template to generate the front-end request code. This replaces manual development of front-end request code, improving efficiency, significantly reducing the workload and error probability of front-end developers, and solving the problems of time-consuming, labor-intensive, and error-prone manual development of front-end request code in existing technologies. Attached Figure Description

[0044] Figure 1 This is a flowchart of a front-end request code generation method according to Embodiment 1 of the present invention;

[0045] Figure 2 This is a schematic diagram of the structure of a front-end request code generation device according to Embodiment 2 of the present invention;

[0046] Figure 3 This is a schematic diagram of the structure of a front-end request code generation device according to Embodiment 3 of the present invention. Detailed Implementation

[0047] To enable those skilled in the art to better understand the technical solution of the present invention, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0048] It is understood that the specific embodiments and accompanying drawings described herein are merely for explaining the invention and are not intended to limit the invention.

[0049] It is understood that, without conflict, the various embodiments and features in the embodiments of the present invention can be combined with each other.

[0050] It is understood that, for ease of description, only the parts related to the present invention are shown in the accompanying drawings, while the parts unrelated to the present invention are not shown in the drawings.

[0051] It is understood that each unit or module involved in the embodiments of the present invention may correspond to only one entity structure, or may be composed of multiple entity structures, or multiple units or modules may be integrated into one entity structure.

[0052] It is understood that, without conflict, the functions and steps marked in the flowcharts and block diagrams of this invention may occur in a different order than that marked in the accompanying drawings.

[0053] It is understood that the flowcharts and block diagrams of this invention illustrate the possible architecture, functions, and operations of systems, apparatuses, devices, and methods according to various embodiments of this invention. Each block in the flowchart or block diagram may represent a unit, module, program segment, or code, containing executable instructions for implementing the specified function. Furthermore, each block or combination of blocks in the block diagram and flowchart can be implemented using a hardware-based system to achieve the specified function, or using a combination of hardware and computer instructions.

[0054] It is understood that the units and modules involved in the embodiments of the present invention can be implemented by software or by hardware. For example, the units and modules can be located in a processor.

[0055] Application Overview

[0056] According to project requirements, the front-end request code needs to be developed and written based on the Swagger documentation provided by the back-end interface. When the front-end developer writes the axios request code, they write the front-end JS request code based on some key information provided in the Swagger documentation. However, manually developing and writing the front-end request code is time-consuming, laborious, and prone to errors.

[0057] Swagger is a popular tool for backend and frontend programmers to interface with each other. It has many standardized features. When backend programmers develop code, they will configure Swagger annotations according to Swagger's fixed requirements to generate Swagger documentation. Therefore, Swagger has strong standardization, consistency and uniformity.

[0058] Axios requests are a popular method for connecting front-end and back-end interfaces. When developing various requests, they are highly standardized for different types of requests. For different interfaces, only different parameters need to be modified to complete the request.

[0059] During the development and writing of Axios request files, the various parameters required are precisely what the Swagger documentation can provide. These parameters are standardized, dynamic, and their patterns can be objectively summarized. However, currently, there are no tools on the market that can automatically generate front-end Axios request code based on online Swagger documentation and local JSON files. Furthermore, developing a tool to automatically generate front-end Axios request code based on Swagger documentation and JSON files presents several challenges:

[0060] 1. Swagger documentation exists in two forms: some companies use an online address, while others use a locally exported JSON file. Therefore, both forms of Swagger documentation should be taken into account during development.

[0061] 2. Because the communication requests between the front-end and back-end include a lot of key information, these need to be summarized and converted into code.

[0062] 3. Swagger documentation may lack some information due to non-standard writing by backend programmers, so some default cases need to be taken into account during development.

[0063] To address the aforementioned technical problems, this application provides a method, apparatus, and readable storage medium for generating front-end request code. By observing and analyzing the mainstream Swagger document structure, key information is extracted from the Swagger data. Based on the key information, target parameters required for the front-end request code are generated. The front-end request code is then generated using the target parameters and a preset front-end request code template. This replaces the manual work of developing and writing front-end request code, improving efficiency and significantly reducing the workload and error probability of front-end personnel. This at least solves the problems of time-consuming, labor-intensive, and error-prone manual development and writing of front-end request code in the prior art.

[0064] After introducing the basic principles of this application, various non-limiting embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0065] Example 1:

[0066] This embodiment provides a method for generating front-end request code, such as Figure 1 As shown, the method includes:

[0067] Step S101: Obtain the Swagger data from the Swagger document.

[0068] It should be noted that Swagger documentation is divided into Swagger documentation for network addresses and Swagger documentation for local addresses.

[0069] In one optional embodiment, obtaining the Swagger data from the Swagger document specifically includes:

[0070] Receive the address of the Swagger document;

[0071] Since the address of the Swagger document is a network address, the Swagger data is obtained from the network address using the http module of node.js;

[0072] In response to the fact that the address of the Swagger document is a local address, the Swagger data is retrieved from the local address.

[0073] Specifically, it receives the address of the Swagger document. When it determines that the Swagger document address is a network address, it uses Node.js's http module, sets the returned data format, makes a request to the network address, and concatenates the returned data to obtain the Swagger data from the Swagger document. The specific code can be shown below:

[0074]

[0075] }

[0076] }

[0077] When it is determined that the Swagger document's address is a local address, the `require` function is used to retrieve the Swagger data from the Swagger document. The specific code is shown below:

[0078] swaggerData=require(`${process.cwd()} / ${DOWNLOAD_URL}`)

[0079] Step S102: Generate the target parameters required for the front-end request code based on the key information in the swagger data.

[0080] It should be noted that the target parameters include description information, prefix information, method information, and definition information. The method information includes at least one method object, and each method object includes a request address, request type, request description, request method name, and request parameters.

[0081] In one optional embodiment, generating the target parameters required for the front-end request code based on the key information in the swagger data specifically includes:

[0082] The description information required to generate the front-end request code is generated based on the description information in the Swagger data;

[0083] Generate the prefix information required for the front-end request code based on the domain information in the Swagger data;

[0084] Based on the method information in the Swagger data, generate the request address, request type, request description, and request parameters for each method object required to generate the front-end request code;

[0085] Based on the method information in the swagger data or each of the request addresses, generate the request method name in each method object required to generate the front-end request code;

[0086] The definition information required to generate the front-end request code is generated based on the definition information in the Swagger data.

[0087] In this embodiment, in order to transform the key information in the Swagger data into front-end request code, the description information, prefix information, method information, and definition information required by the core of the front-end request code are generated based on the description information, domain information, method information, and definition information in the Swagger data.

[0088] In one optional embodiment, generating the prefix information required for the front-end request code based on the domain information in the swagger data specifically includes:

[0089] Determine whether the domain information in the Swagger data contains the Schemes field, the host field, and the basePath field;

[0090] In response to the presence of the Schemes, host, and basePath fields in the domain information of the swagger data, the Schemes, host, and basePath fields are concatenated according to a preset concatenation rule to obtain the prefix information.

[0091] In this embodiment, since the frontend request access method is divided into HTTP and HTTPS, it needs to be dynamically configured and generated. By judging whether the domain information in the Swagger data contains schemas, host, and basePath, the prefix information is concatenated according to the rules. The specific code can be shown below:

[0092] domain:(swagger.schemes&&swagger.schemes.length>0&&

[0093] swagger.host&&swagger.basePath)? swagger.schemes[0]+': / / '+

[0094] swagger.host+swagger.basePath.replace( / \ / +$ / g,”):”,

[0095] In one optional embodiment, the step of generating the request method name in each method object required for the front-end request code based on the method information in the swagger data or each of the request addresses specifically includes:

[0096] For each method object, determine whether the operation identifier (operationId) of the method object exists in the method information of the swagger data;

[0097] In response to the existence of the operationId of the method object in the method information of the swagger data, special characters and spaces in the operationId are removed using regular expressions, the split method, and the join method to obtain the request method name in the method object;

[0098] If the operationId of the method object is not found in the method information of the swagger data, the request method name of the method object is generated based on the request address in the method object.

[0099] In this embodiment, since the operationId of a method object may not be set during the backend development process, for each method object, if the operationId of that method object exists in the method information in the Swagger data, special characters in the operationId are removed using regular expressions, and then possible spaces are removed using split("").join("_") to obtain the request method name of that method object. The specific code is as follows:

[0100] let fixName = function(id){

[0101] return id.replace( / \.|\-|\{|\} / g,′_′).split("").join("_")

[0102] }

[0103] If the operationId of the method object does not exist in the method information in the Swagger data, the request method name in the method object is generated based on the request address in the method object.

[0104] Specifically, the method for generating the request method name in the method object based on the request address is as follows: The request address is split; the `transform` method in lodash is used to determine if a code block separator exists in the split request address; if a code block separator exists in the split request address, it is replaced; the `camelCase` method in lodash is used to process the replaced request address into camelCase; and the request method name is obtained based on the camelCase-processed request address. The specific code can be shown below:

[0105] let getPathToMethodName=function(opts,m,path){

[0106] if(path====′ / ′||path====”){

[0107] return m

[0108] }

[0109] let cleanPath=path.replace( / \ / $ / ,”)

[0110] let segments=cleanPath.split(' / ′).slice(1)

[0111] segments=_.transform(segments,function(result,segment){

[0112] if(segment[0]==='{'&&segment[segment.length-1]===='}'){

[0113] segment='by'+segment[1].toUpperCase()+

[0114] segment.substring(2,segment.length-1)

[0115] }

[0116] result.push(segment)

[0117] })

[0118] let result=_.camelCase(segments.join('-'))

[0119] return m.toLowerCase()+result[0].toUpperCase()+

[0120] result.substring(1)

[0121] }

[0122] In an optional embodiment, after generating the request address, request type, request description, and request parameters of each method object required for the front-end request code based on the method information in the swagger data, the method further includes:

[0123] The request format of the request parameters in each of the method objects is specially identified and recorded.

[0124] In this embodiment, the request format of the request parameters includes body format, path format, query format, formData format, etc., which are reflected in the corresponding fields in Swagger data. The request format of the request parameters in each method object is specially identified and recorded for subsequent processing.

[0125] Step S103: Generate the front-end request code according to the preset front-end request code template and the target parameters.

[0126] It should be noted that the preset code template for front-end requests may include a first code template and a second code template.

[0127] In one optional embodiment, generating the front-end request code based on a preset front-end request code template and the target parameters specifically includes:

[0128] Register the code template;

[0129] Based on the target parameters and each recorded unique identifier, the registered code template is assigned a value to obtain the front-end request code.

[0130] Specifically, the handlebars package is used to register the preset first code template and second code template. The first code template is used to iterate through each method object in the method information of the target parameters. Then, the second code template is referenced. For each method object, according to the target parameter part and special identifier of the method object, the template part of the request format corresponding to the method object in the second code template is assigned a value to obtain the front-end request code.

[0131] It should be noted that after generating the front-end request code, you can use the fs module in Node.js to write the front-end request code into the corresponding file.

[0132] In one specific embodiment, the present invention completes the entire process through the following steps, which are described in detail below:

[0133] I. Language Introduction

[0134] JavaScript is a lightweight, interpreted or just-in-time (JIT) programming language that prioritizes functions and is primarily used in browsers. However, because it involves manipulating files (creating, writing, modifying, deleting, and saving), Node.js is needed to accomplish this functionality.

[0135] II. Overall Architecture Design

[0136] 1. Design the index.js main entry file, which is the main logic file, to receive user parameters and call the written plugins.

[0137] 2. Design a methods folder, which includes:

[0138] The download request file is used to request and download data from the Swagger network address.

[0139] The template file contains three templates, which are the code templates for the front-end axios requests that will be output in the end.

[0140] The codeFormat file is used to integrate the three templates of the template file, read the template code, and register it.

[0141] The Utils file contains some used tools / public methods. It also differentiates between different Swagger versions and handles them differently.

[0142] The Index file imports and executes util and codeFormat, and finally exposes the main method for calling.

[0143] III. Method Implementation

[0144] 1. Add the execution script to package.json, the specific code is as follows:

[0145] "scripts":{

[0146] "getapi":"node. / src / index.jsDOWNLOAD_URL=. / hlj_develop_branch.jsonOUTPUT=. / autoapi.js"

[0147] },

[0148] Here, `node node_modules / swagger2axios / src / index.js` means using Node.js to execute the `index.js` file in the core package. `DOWNLOAD_URL` is the specified Swagger path, which can be an HTTP network path or a local JSON file path, used to retrieve Swagger information. `OUTPUT` is the input path for the final result generated after processing Swagger.

[0149] 2. After executing the script, the main logic of index.js is entered. First, the necessary methods and modules are imported into the main logic, the parameters of the executed script are obtained, and then the core module is processed. First, the Swagger data is obtained, the Swagger data is processed, and finally the file is output. The specific code is as follows:

[0150] const codeFormat2Method=require('. / methods')

[0151] let OUTPUT=′autoApi.js′;

[0152] let DOWNLOAD_URL='swagger.json′

[0153]

[0154] 2.1 Obtain Swagger data. After determining the source of the Swagger data by the prefix of the parameter, it is obtained in two ways:

[0155] The first type of network address involves using a network address as a parameter in the script's input. In this case, Node.js's `http` module needs to be used to configure the returned data format, request the address, and then concatenate the returned data. The specific code is as follows:

[0156]

[0157] The second method uses a local address. When the Swagger address is a local relative path JSON address in the input parameters of the executed script, the `require` function is used to import the JSON file and return the required Swagger file. The specific code is as follows:

[0158] swaggerData=require(`${process.cwd()} / ${DOWNLOAD_URL}`)

[0159] 2.2 Processing Swagger data: First, use `getViewData` to retrieve the core data from the Swagger file, perform formatting modifications, and then use `codeFormat` to modify the template of the collected data. The specific code is as follows:

[0160] const getViewData=require(′. / util.js′)

[0161] const codeFormat=require('. / codeFormat.js′)

[0162] module.exports=function(opt){

[0163] let data = getViewData(opt)

[0164] let codeResult=codeFormat(data)

[0165] return codeResult

[0166] }

[0167] 2.2.1 Core content of the getViewData method

[0168] Considering the different Swagger versions, Swagger 1.0 and Swagger 2.0 require different processing methods due to their different returned data structures. Taking the mainstream Swagger 2 version as an example, the core is to define the required data format, including the core attributes to be collected: description (i.e., the descriptive information needed to generate the core front-end request code), domain (i.e., the prefix information needed to generate the core front-end request code), and methods.

[0169] (That is, the method information needed to generate the core of the front-end request code), definitions (that is, the definition information needed to generate the core of the front-end request code), the specific code is as follows:

[0170] let data = {

[0171] description:swagger.info.description,

[0172] isSecure:swagger.securityDefinitions! ==undefined,

[0173] moduleName:opts.moduleName,

[0174] className:opts.className,

[0175] imports:opts.imports,

[0176] domain:(swagger.schemes&&swagger.schemes.length>0

[0177] &&swagger.host&&swagger.basePath)? swagger.schemes[0]+′: / / '+swagger.host+swagger.basePath.replace( / \ / +$ / g,”):”,

[0178] methods:[],

[0179] definitions:[

[0180] }

[0181] In this plugin, `domain` serves as a common prefix for all requests. It's important to note that because requests can be accessed via HTTP or HTTPS, it needs to be dynamically generated. Here, if the `schemes`, `host`, and `basePath` exist in the documentation, they are concatenated according to rules to create a dynamic request prefix. The specific code is as follows:

[0182] domain:(swagger.schemes&&swagger.schemes.length>0&&

[0183] swagger.host&&swagger.basePath)? swagger.schemes[0]+': / / '+

[0184] swagger.host+swagger.basePath.replace( / \ / +$ / g,”):”,

[0185] The `methods` array is used here to store the `method` objects (i.e., method objects) of multiple interfaces in the Swagger documentation. Each `method` object declares some properties that will be used later, including fields such as `path` (request URL), `method` (request type), and `summary` (request description). The specific code is as follows:

[0186]

[0187]

[0188] Here, `methodName` is the request method name, which requires special handling. During backend development, there might be instances where a unique identifier like `operationId` is not set, so two methods are prepared:

[0189] If `operationId` exists, it is processed using the `fixName` method. Regular expressions are used to remove special characters from `operationId`, and then `split("").join("_")` is used to remove any possible whitespace. The specific code is as follows:

[0190] let fixName = function(id){

[0191] return id.replace( / \.|\-|\{|\} / g,′_′).split("").join("_")

[0192] }

[0193] When the operationId does not exist, the getPathToMethodName method handles some special cases of the path. Because the path (i.e., the request address) may contain "{}", it needs to be replaced. Therefore, the path is split, and the transform method in the lodash package is used to loop through and check if "{}" exists. If it does, the "{" is replaced with "by", then camelCase is applied and the "}" is removed. Then, the camelCase method in lodash is used to process the replaced result into camelCase. Finally, the method (the keyword of the request type under the path loop) and the camelCase result are concatenated with the first letter capitalized to complete the generation of the new methodName. The specific code is as follows:

[0194]

[0195]

[0196] There are many ways for backend interfaces to receive frontend parameters (i.e., request parameters), and Swagger has corresponding fields for this. To allow templates to handle different formats in different ways, special processing is needed. Formats such as "body", "path", "query", and "formData" need to be specially identified and recorded. The specific code is as follows:

[0197]

[0198]

[0199] 2.2.2 Core content of the codeFormat method

[0200] The overall approach is to write the necessary template files for the front-end requests, and while outputting them, use the handlebars package to register two pre-made template files. Then, extract the previously processed Swagger data and finally merge them. The specific code is as follows:

[0201] const methods=fs.readFileSync(path.join(__dirname,

[0202] ′. / template / methods.hbs'),'utf-8′)

[0203] const method=fs.readFileSync(path.join(__dirname,

[0204] ′. / template / method.hbs'),'utf-8′)

[0205] Handlebars.registerPartial('methods',methods)

[0206] Handlebars.registerPartial('method',method)

[0207] The `methods` template is used to loop through the `methods` parameter, then reference the `methods` template for output. The specific code is as follows:

[0208]

[0209]

[0210] The method body uses the standard axios request format (this template can be extended if other request methods, such as AJAX, are needed). It loops through the parameters and then utilizes special identifiers from the previous data.

[0211] When isQueryParameter is true, meaning the request format is query, a queryParameters object is created, and the corresponding parameters are dynamically placed into it. queryParameters['{{&name}}'] = parameters['{{&camelCaseName}}'] means that a dynamic key is declared in the queryParameters object, which takes the name variable and the value is the camelCaseName key in parameters. Both are dynamically obtained.

[0212] When isPathParameter is true, meaning the request format is path, the corresponding path is created and modified. The "brackets name" in the path is dynamically replaced, and the value is camelCaseName, which is dynamically obtained from the parameters.

[0213] When isBodyParameter is true, meaning the request format is body, a body object is created with the key camelCaseName from parameters as its value. All values ​​are dynamically retrieved. The same process applies to other request formats. The specific code is as follows:

[0214]

[0215]

[0216]

[0217] 2.3 Finally, the data is output using the `writeFileSync` method of Node.js's `fs` module. The path to the currently executing script and the path to the `output` parameter (from the initial parameters of the script) are dynamically obtained from the parameters. The specific code is as follows:

[0218] const codeResult=codeFormat2Method(opt)

[0219] const fs = require('fs')

[0220] fs.writeFileSync(`${process.cwd()} / ${OUTPUT}`,codeResult)

[0221] It is worth mentioning that this invention utilizes JavaScript and Node.js to manipulate files. It dynamically generates JS files by reading Swagger files from variables (request address, request method, request parameters, etc.) in the front-end axios request code, thus automatically writing axios requests. For online Swagger documents, it uses requests to obtain information returned by the Swagger interface. For local JSON Swagger documents, Node.js is used to read and write the files, and finally, the desired axios request file format is output. This invention observes and analyzes the structure of mainstream interface documents (Swagger), extracts key information using JS, and then performs code transformation on the key Swagger information, including the declaration of method objects and the setting of keywords, and the formulation of compatibility rules for the request method name (methodName). Then, Handlebars is used for template assignment, including separate processing of different request methods in the method template, and finally, the code is output, thus replacing manual repetitive work and improving efficiency.

[0222] The front-end request code generation method provided in this invention first obtains Swagger data from a Swagger document; then, it generates target parameters required for the front-end request code based on key information in the Swagger data; finally, it generates the front-end request code based on a preset front-end request code template and the target parameters. This invention, through observation and analysis of mainstream Swagger document structures, extracts key information from the Swagger data, generates target parameters required for the front-end request code based on this key information, and uses the target parameters and a preset front-end request code template to generate the front-end request code. This replaces the manual work of developing and writing front-end request code, improving efficiency, significantly reducing the workload of front-end developers and the probability of errors, and solving the problems of time-consuming, labor-intensive, and error-prone manual development of front-end request code in existing technologies.

[0223] Example 2:

[0224] like Figure 2 As shown, this embodiment provides a front-end request code generation apparatus for executing the aforementioned front-end request code generation method, including:

[0225] Module 11 is used to retrieve Swagger data from the Swagger documentation;

[0226] The first generation module 12, connected to the acquisition module 11, is used to generate the target parameters required for the front-end request code based on the key information in the swagger data.

[0227] The second generation module 13, connected to the first generation module 12, is used to generate the front-end request code according to the preset front-end request code template and the target parameters.

[0228] Furthermore, the acquisition module 11 specifically includes:

[0229] A receiving unit is used to receive the address of the swagger document;

[0230] The first acquisition unit is used to retrieve the swagger data from the network address using the http module of node.js in response to the fact that the address of the swagger document is a network address;

[0231] The second acquisition unit is used to acquire the swagger data from the local address in response to the swagger document's address being a local address.

[0232] Further, the target parameters include description information, prefix information, method information, and definition information. The method information includes at least one method object, and each method object includes a request address, request type, request description, request method name, and request parameters. The first generation module 12 specifically includes:

[0233] The first generation unit is used to generate the description information required for the front-end request code based on the description information in the swagger data;

[0234] The second generation unit is used to generate the prefix information required by the front-end request code based on the domain information in the swagger data;

[0235] The third generation unit is used to generate the request address, request type, request description and request parameters of each method object required by the front-end request code based on the method information in the swagger data;

[0236] The fourth generation unit is used to generate the request method name in each method object required by the front-end request code based on the method information in the swagger data or each request address;

[0237] The fifth generation unit is used to generate the definition information required for the front-end request code based on the definition information in the Swagger data.

[0238] Furthermore, the second generation unit specifically includes:

[0239] The first judgment unit is used to determine whether the domain information in the swagger data contains the protocol Schemes field, the host field, and the basePath field;

[0240] The concatenation unit is used to respond to the presence of the Schemes field, host field, and basePath field in the domain information of the swagger data, and to concatenate the Schemes field, host field, and basePath field according to a preset concatenation rule to obtain the prefix information.

[0241] Furthermore, the fourth generation unit specifically includes:

[0242] The second judgment unit is used to determine, for each method object, whether the operation identifier (operationId) of the method object exists in the method information of the swagger data;

[0243] The removal unit is used to remove special characters and spaces in the operationId of the method object in the method information of the swagger data using regular expressions, the split method, and the join method to obtain the request method name in the method object.

[0244] The sixth generation unit is used to generate the request method name in the method object based on the request address in the method object in response to the absence of the operationId of the method object in the method information of the swagger data.

[0245] Furthermore, the sixth generation unit specifically includes:

[0246] A segmentation unit is used to segment the request address;

[0247] The third judgment unit is used to determine whether there is a code block separator in the segmented request address using the transform method in lodash;

[0248] The replacement unit is used to replace the code block separator if a code block separator exists in the segmented request address.

[0249] The camelCase processing unit is used to process the replaced request address using the camelCase method in lodash.

[0250] The obtaining unit is used to obtain the request method name based on the request address after processing with camelCase.

[0251] Furthermore, the first generation module 12 also includes:

[0252] The recording unit is used to specially identify and record the request format of the request parameters in each of the method objects.

[0253] Furthermore, the second generation module 13 specifically includes:

[0254] A registration unit is used to register the code template;

[0255] The assignment unit is used to assign values ​​to the registered code template according to the target parameters and each special identifier recorded, so as to obtain the front-end request code.

[0256] Example 3:

[0257] refer to Figure 3This embodiment provides a front-end request code generation apparatus, including a memory 21 and a processor 22. The memory 21 stores a computer program, and the processor 22 is configured to run the computer program to execute the front-end request code generation method in Embodiment 1.

[0258] The memory 21 is connected to the processor 22. The memory 21 can be a flash memory, a read-only memory or other memory, and the processor 22 can be a central processing unit or a microcontroller.

[0259] Example 4:

[0260] This embodiment provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the front-end request code generation method in Embodiment 1 above.

[0261] The computer-readable storage medium includes volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, computer program modules, or other data). Computer-readable storage media include, but are not limited to, RAM (Random Access Memory), ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other memory technologies, CD-ROM (Compact Disc Read-Only Memory), DVD or other optical disc storage, cartridges, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer.

[0262] In summary, the front-end request code generation method, apparatus, and readable storage medium provided in this invention first obtain Swagger data from a Swagger document; then, based on key information in the Swagger data, generate target parameters required for the front-end request code; and finally, generate the front-end request code based on a preset front-end request code template and the target parameters. This invention, through observation and analysis of mainstream Swagger document structures, extracts key information from the Swagger data, generates target parameters required for the front-end request code based on this key information, and uses the target parameters and a preset front-end request code template to generate the front-end request code. This replaces manual development of front-end request code, improves efficiency, significantly reduces the workload of front-end developers and the probability of errors, and solves the problems of time-consuming, labor-intensive, and error-prone manual development of front-end request code in existing technologies.

[0263] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of the present invention, and the present invention is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and essence of the present invention, and these modifications and improvements are also considered to be within the scope of protection of the present invention.

Claims

1. A method for generating front-end request code, characterized in that, The method includes: Retrieve Swagger data from the Swagger documentation; Generate the target parameters required for the front-end request code based on the key information in the Swagger data; The front-end request code is generated based on the preset front-end request code template and the target parameters.

2. The method according to claim 1, characterized in that, The process of obtaining Swagger data from the Swagger document specifically includes: Receive the address of the Swagger document; Since the address of the Swagger document is a network address, the Swagger data is obtained from the network address using the http module of node.js; In response to the fact that the address of the Swagger document is a local address, the Swagger data is retrieved from the local address.

3. The method according to claim 1, characterized in that, The target parameters include description information, prefix information, method information, and definition information. The method information includes at least one method object, and each method object includes a request address, request type, request description, request method name, and request parameters. The step of generating the target parameters required for the front-end request code based on the key information in the Swagger data specifically includes: The description information required to generate the front-end request code is generated based on the description information in the Swagger data; Generate the prefix information required for the front-end request code based on the domain information in the Swagger data; Based on the method information in the Swagger data, generate the request address, request type, request description, and request parameters for each method object required to generate the front-end request code; Based on the method information in the swagger data or each of the request addresses, generate the request method name in each method object required to generate the front-end request code; The definition information required to generate the front-end request code is generated based on the definition information in the Swagger data.

4. The method according to claim 3, characterized in that, The step of generating the prefix information required for the front-end request code based on the domain information in the Swagger data specifically includes: Determine whether the domain information in the Swagger data contains the Schemes field, the host field, and the basePath field; In response to the presence of the Schemes, host, and basePath fields in the domain information of the swagger data, the Schemes, host, and basePath fields are concatenated according to a preset concatenation rule to obtain the prefix information.

5. The method according to claim 3, characterized in that, The step of generating the request method name in each method object required for the front-end request code based on the method information in the swagger data or each request address specifically includes: For each method object, determine whether the operation identifier (operationId) of the method object exists in the method information of the swagger data; In response to the existence of the operationId of the method object in the method information of the swagger data, special characters and spaces in the operationId are removed using regular expressions, the split method, and the join method to obtain the request method name in the method object; If the operationId of the method object is not found in the method information of the swagger data, the request method name of the method object is generated based on the request address in the method object.

6. The method according to claim 5, characterized in that, The step of generating the request method name in the method object based on the request address in the method object specifically includes: The request address is split; Use the transform method in lodash to determine whether there are code block separators in the segmented request address; If a code block separator exists in the segmented request address, then the code block separator will be replaced. The camelCase method in lodash is used to process the replaced request address into camelCase; The request method name is obtained from the request address after processing with camelCase.

7. The method according to claim 3, characterized in that, After generating the request address, request type, request description, and request parameters for each method object required for the front-end request code based on the method information in the Swagger data, the method further includes: The request format of the request parameters in each of the method objects is specially identified and recorded.

8. The method according to claim 7, characterized in that, The step of generating the front-end request code based on the preset front-end request code template and the target parameters specifically includes: Register the code template; Based on the target parameters and each recorded unique identifier, the registered code template is assigned a value to obtain the front-end request code.

9. A front-end request code generation device, characterized in that, include: The retrieval module is used to retrieve Swagger data from the Swagger documentation. The first generation module, connected to the acquisition module, is used to generate the target parameters required for the front-end request code based on the key information in the swagger data. The second generation module, connected to the first generation module, is used to generate the front-end request code based on a preset front-end request code template and the target parameters.

10. A front-end request code generation device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to implement the front-end request code generation method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the front-end request code generation method as described in any one of claims 1-8.

Images