CN115729593A - Request status code processing method and device, electronic equipment and storage medium - Google Patents

Abstract

The embodiment of the application provides a request status code processing method and device, electronic equipment and a storage medium, and relates to the technical field of interface processing. The method comprises the steps of responding to an API call request, and obtaining a user-defined configuration rule; combining the user-defined configuration rule with a preset embedded point rule and a preset state code rule in a rule engine to generate a synthesis rule; the method generates the API processing function based on the synthesis rule, the configuration file and the status code generation template, uniformly requests the status code processing for various configuration rules of the scene, forms a merging rule with a user-defined configuration rule, can automatically generate the API processing function according to the configured merging rule, and solves the problems of high updating and maintaining cost and repeated development of the strongly-coupled API in the existing method.

Description

Request status code processing method and device, electronic equipment and storage medium

Technical Field

The present application relates to the field of interface processing technologies, and in particular, to a method and an apparatus for processing a request status code, an electronic device, and a storage medium.

Background

In the process of service development, interactive service requirements are often required to be processed. Usually, the method is implemented by calling a back-end API, and a common processing method is to write an API processing function and perform corresponding processing on request parameters and response data of an interface. The API processing function needs to process different status code scenarios, which may appear multiple times in different projects, and different scenarios may follow the API definition, exist in different API processing functions, and form a strong coupling with the system.

When the processing scenes distributed in different projects meet the update API of the back end in the later period, the front end needs a large amount of work to collect and synchronously modify; or considering that the change results in too many associations, the original API update may be abandoned, and thus a set of APIs needs to be redefined. In the process, the reuse rate of the existing codes is reduced, and unnecessary cost is brought to the conventional updating and maintenance of the system; meanwhile, in the development stage, developers need to repeatedly process the same scene, which causes waste of manpower.

Disclosure of Invention

The embodiments of the present application aim to provide a method, an apparatus, an electronic device, and a storage medium for processing a request status code, which perform unified request status code processing on various configuration rules of a scene, and form a merge rule with a user-defined configuration rule, so that an API processing function can be automatically generated according to the configured merge rule, thereby solving the problems of high cost and repeated development of API update and maintenance strongly coupled in the existing method.

The embodiment of the application provides a method for processing a request status code, which comprises the following steps:

responding to the API call request, and acquiring a user-defined configuration rule;

combining the user-defined configuration rule with a preset embedded point rule and a preset state code rule in a rule engine to generate a synthesis rule;

and generating an API processing function based on the synthesis rule, the configuration file and the state code generation template.

In the implementation process, the state code rule, the embedded point rule and the like are independently extracted to carry out unified request state code processing, the state code rule and the embedded point rule form a universal combination rule with a user-defined configuration rule, an API processing function can be automatically generated according to the configured combination rule, and the problems that the API updating and maintaining cost is high and the API is repeatedly developed in the strong coupling mode in the existing method are solved.

Further, before the step of obtaining the user-defined configuration rule, the method includes:

and performing API configuration based on JSON data, wherein the configuration comprises an API function name, whether the API function name is an asynchronous function, whether the cache is enabled, and whether the execution track is recorded through a felog.

In the implementation process, JSON data is used for describing the scenes required by the API function generation rules and the logic response.

Further, before the step of obtaining the user-defined configuration rule, the method includes:

and performing URL configuration based on JSON data, wherein the configuration comprises an interface address, a domain name placeholder, interface description information, a reference type, a default value and a return value.

In the implementation process, interface rules are described through JSON data, and when the calling API function is generated, the interface rules are used for verifying the input and output parameter logic.

Further, before the step of merging the user-defined configuration rule with the embedded point rule and the state code rule preset in the rule engine, the method includes configuring a state code rule:

configuring multiple state strategies before and after the API call request response, and responding the state strategies by different state code processing functions in a combined mode.

In the implementation process, the state code rule provides various state policies before and after the request response stage and responds to the state policies.

Further, before the step of merging the user-defined configuration rule with the embedded point rule and the state code rule preset in the rule engine, the method includes generating an embedded point rule:

and acquiring a state code rule, and generating a buried point rule based on the state code rule.

In the implementation process, an automatic point burying strategy is set, and a universal point burying rule is generated according to the collected state code rule.

An embodiment of the present application further provides a device for processing a request status code, where the device includes:

the user rule obtaining module is used for responding to the API call request and obtaining a user-defined configuration rule;

the synthesis module is used for combining the user-defined configuration rule with a preset embedded point rule and a preset state code rule in a rule engine to generate a synthesis rule;

and the function generation module is used for generating an API processing function based on the synthesis rule, the configuration file and the state code generation template.

In the implementation process, the state code rule, the embedded point rule and the like are extracted independently to perform unified request state code processing, the unified request state code processing and the user-defined configuration rule form a universal combination rule, an API processing function can be automatically generated according to the configured combination rule, and the problems that the strongly-coupled API updating maintenance cost is high and the development is repeated in the existing method are solved.

Further, the apparatus further comprises:

and the API configuration module is used for carrying out API configuration based on JSON data, and the configuration comprises an API function name, whether the function is an asynchronous function, whether the cache is started and whether an execution track is recorded through a felog.

In the implementation process, JSON data is used for describing scenes needed by the API function generation rule and the logic response.

Further, the apparatus further comprises:

and the URL configuration module is used for carrying out URL configuration based on JSON data, and the configuration comprises an interface address, a domain name placeholder, interface description information, a reference type, a default value and a return value.

In the implementation process, interface rules are described through JSON data, and when the calling API function is generated, the interface rules are used for checking the input and output parameter logics.

An embodiment of the present application further provides an electronic device, where the electronic device includes a memory and a processor, where the memory is used to store a computer program, and the processor runs the computer program to enable the electronic device to execute the request status code processing method described in any one of the foregoing descriptions.

An embodiment of the present application further provides a readable storage medium, where computer program instructions are stored, and when the computer program instructions are read and executed by a processor, the method for processing a request status code is performed.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.

Fig. 1 is a flowchart of a request status code processing method according to an embodiment of the present disclosure;

fig. 2 is a flowchart of a general request status code processing provided in an embodiment of the present application;

FIG. 3 is a flowchart of an API processing function generation provided by an embodiment of the present application;

FIG. 4 is a schematic diagram of an API configuration provided by an embodiment of the present application;

FIG. 5 is a schematic view of a URL configuration provided by an embodiment of the present application;

fig. 6 is a processing flow of status codes according to an embodiment of the present application;

fig. 7 is a block diagram illustrating a request status code processing apparatus according to an embodiment of the present disclosure;

fig. 8 is a block diagram of another request status code processing apparatus according to an embodiment of the present disclosure.

Icon:

100-a user rule obtaining module; 200-a synthesis module; 210-API configuration module; 220-URL configuration module; 230-a status code rule configuration module; 240-buried point rule generating module; 300-function generation module.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only for distinguishing the description, and are not to be construed as indicating or implying relative importance.

Example 1

Referring to fig. 1, fig. 1 is a flowchart illustrating a request status code processing method according to an embodiment of the present disclosure. The method is to decouple the API, the state code and the API processing function from the system from the source, extract the contents such as API setting, URL setting and the like which change based on different state code scenes and package the contents into a rule engine, and under different scenes, the method can respond to a front-end request based on the configuration in the rule engine and automatically generate the corresponding API processing function. As shown in fig. 2, it is a general request status code processing flow chart, which specifically includes the following steps:

step S100: responding to the API call request, and acquiring a user-defined configuration rule;

step S200: combining the user-defined configuration rule with a point burying rule and a state code rule preset in the rule engine to generate a synthesis rule;

step S300: and generating an API processing function based on the synthesis rule, the configuration file and the state code generation template.

The method comprises the steps of independently extracting a state code rule, a point burying rule and the like, uniformly requesting state code processing, packaging the state code rule and the point burying rule into a rule engine, forming a merging rule by a user-defined configuration rule, the state code rule, the point burying rule and the like when the method is used, automatically generating an API processing function according to the configured merging rule after receiving an API calling request from a front end, avoiding the need of developers to repeatedly process the same scene, avoiding manpower waste, reducing updating and maintaining cost, and solving the problems of high updating and maintaining cost and repeated development of the API strongly coupled by the existing method.

The rules engine in fig. 2 internally contains a class 4 state machine: configuration of the API, URL configuration, status code rules and automatic point burying rules, and configurable policies are used in processing the configuration of the API, the URL configuration, the status code rules and the automatic point burying rules.

Before step S200, the class 4 state machine needs to be configured and the API configuration, URL configuration, state code rule and automatic buried point rule are encapsulated into the rule engine.

The four types of state machines based on different scenes are packaged into the rule engine through unified request state code processing, and the original high-coupling interface API flow can be split into configuration. Moreover, by centrally managing the configuration policy formed by the four types of state machines, the API interface can be bound with the configuration to satisfy the switching between different items, and a set of processes is shared, as shown in fig. 2, in response to a front-end request, a corresponding API processing function can be generated by a rule engine.

In the development stage, the API processing function is automatically generated according to the configuration, the problem of scene inconsistency caused by the handwriting flow is reduced, and the adaptation of multiple scenes can be met through the free combination of users, so that the multiplexing rate of the API interface is improved.

In the maintenance stage, the extracted general configuration can be managed in the DEV plug-in unit in a centralized mode, so that unified maintenance can be achieved when maintenance or API back-end requirements change, logic does not need to be updated in all items using the API interface, and maintenance cost is greatly reduced.

As shown in fig. 3, a flowchart is generated for the API processing function, and the development server is started by the npm run dev script during development; the API plug-in of the development service can obtain the user-defined configuration rule in the project (the constraint in the plug-in is configured in the file under the 'src/attributes/request' directory of the local project); the acquired user configuration is combined with a built-in embedded point rule and a general state code configuration rule of the plug-in; and finally, distributing the configuration to a Generator tool, and finally generating the API processing function through configuration and an ejs template engine in the generation tool.

Before the step of obtaining the user-defined configuration rule, the method comprises:

and performing API configuration based on JSON data, wherein the configuration comprises the name of an API function, whether the API function is an asynchronous function, whether caching is enabled and whether the trace is executed through a felog record.

As shown in fig. 4, which is a schematic diagram of API configuration, JSON data is used to describe API processing function generation rules and logic during API configuration, and respond to a required scenario. Specifically, the API configuration includes: name is the Name of the API function;

async: indicating whether the function is an asynchronous function;

and (4) Cache: whether caching is enabled;

track: whether to record an execution trace by the felog.

The specific codes are as follows:

API configuration:

const api＝{

name:'getUserInfo',

async:true,

cache:true,

track:true

}。

API processing function template (ejs syntax):

<％＝api.async？'async':”％>function<％＝api.name％>(){

try{

<％if(api.cache){％>

const result＝<％＝uri.name％>.cache||await POST('<％＝api.name％>')return(<％＝api.name％>.cache＝result.data)

<％}else{％>

const result＝await POST('<％＝uri.name％>')

return result.data||{}

<％}％>

}catch(error){

<％if(api.track){％>

felog.error(new RequestError(error.message,error.code))

<％}else{％>

console.error(error)

<％}％>

}。

before the step of obtaining the user-defined configuration rule, the method comprises:

and performing URL configuration based on JSON data, wherein the configuration comprises an interface address, a domain name placeholder, interface description information, a reference type, a default value and a return value.

FIG. 5 is a schematic diagram of URL configuration. Describing interface rules through JSON data, when generating a calling API function, checking input and output logic, and acquiring data returned by an interface as required by configuring a URL (uniform resource locator), wherein the URL configuration specifically comprises the following steps:

url is an interface address provided by the back end;

host: configuring an RMB or RSB domain name placeholder, dynamically replacing the domain name with a real domain name in a request stage, and supporting dynamic adaptation test and production environment;

label: interface description information which can be provided for the felog and used for recording key information;

params: parameter types and default values can be configured;

result: the return value content may be configured.

And (3) URL configuration:

const getUserInfo＝{

name:'/api/getUserInfoById',

host:'RMB',

label: 'acquiring user information',

params:{

userId:'id123'

},

result:['data','list']

}

const URIS＝{getUserInfo}。

before the step of combining the user-defined configuration rule with the embedded point rule and the state code rule preset in the rule engine, the method comprises the following steps:

and configuring a plurality of state strategies before and after the API call request response, and responding the state strategies by different state code processing functions in a combined mode.

As shown in fig. 6, for the status code processing flow, the status code rule provides various status policies before and after the request response, and different processing functions respond to the status policies in a combined manner, as 900106 indicates that the interface needs to log in.

The status code processing rule code is as follows:

const codeActions＝{

'000000':true,

900106 [ 'resource absence', 'ERROR' ]

}

const funs＝{

ERROR(err){

throw err

}

Cut-to-

}。

Before the step of merging the user-defined configuration rule with the embedded point rule and the state code rule preset in the rule engine, the method includes the steps of:

and acquiring a state code rule, and generating a buried point rule based on the state code rule.

According to the automatic point burying strategy, a universal point burying rule is generated according to collected state code rules, for example, state codes such as 200 and 000000 belong to a conventional state, the state codes are defined as LOG types when the buried points are configured, and a final execution stage calls a felog.

API and status code processing function

async function codeMessage(uri,response){

const{code,errorMessage}＝response

// match status code

const action＝codeActions[code]

if(action){

const[message,level]＝action

const error＝new Error(message||errorMessage)

error.code＝code

// deciding on a processing strategy according to rank

if(level＝＝＝'ERROR'){

funs[level](error)

}else{

console.log(error)

}

}

Cut to

// configuring the Return results according to uri

for(const key in uri.result){

const value＝uri.result[key]

if(response[value]){

return response[value]

}

}

Cut to

// handle unconfigured State, return by default

return response.data

}

// API handle function

async function POST(url){

const uri＝URIS[url]

// Call the underlying request function

const response＝await aladdin.http.request(uri)

......

v/Exception intercept, have Exception, throw Exception. And processing exceptions (processing in codeMessage function) according to the status code rules

const{error,data}＝await codeMessage(uri,response)

if(error){

throw new PostError(error.message,error.code)

}

......

V. No abnormal conditions, return to return data normally

return data

}。

The generated API processing function can be put into a temporary directory (. Own/API /) of the development environment in the form of a file, and the service code can be directly used through an deconstruction syntax ' import { getUserInfo } from ' @/API ' through a mapping path in the development tool.

Through the processing of the universal request state code, when a front-end API call request is processed, the API processing function can be generated through simple packaging and combination through the set state code rules, corresponding business logic can be realized, various possible abnormal states of the API interface in the return stage do not need to be processed intentionally, the labor consumption of developers is reduced, and the developers can concentrate on the development of normal business processes in the field of financial science and technology.

Example 2

An embodiment of the present application provides a request status code processing apparatus, which is applied to the request status code processing method described in embodiment 1, and as shown in fig. 7, is a block diagram of a structure of the request status code processing apparatus, where the apparatus includes but is not limited to:

a user rule obtaining module 100, configured to respond to the API call request and obtain a user-defined configuration rule;

a synthesis module 200, configured to combine the user-defined configuration rule with a preset embedded point rule and a preset status code rule in a rule engine to generate a synthesis rule;

a function generating module 300, configured to generate an API processing function based on the synthesis rule, the configuration file, and the status code generating template.

As shown in fig. 8, which is a block diagram of another request status code processing apparatus, on the basis of fig. 7, the apparatus further includes:

and the API configuration module 210 is used for conducting API configuration based on JSON data, wherein the configuration comprises the name of an API function, whether the API function is an asynchronous function, whether caching is enabled and whether an execution track is recorded through a felog.

JSON data is used to describe the scenario required by the API function generation rules and the logical response.

And the URL configuration module 220 is configured to perform URL configuration based on JSON data, where the configuration includes an interface address, a domain name placeholder, interface description information, a reference type, a default value, and a return value.

And describing an interface rule through JSON data, and checking the input and output logic when generating and calling the API function.

A status code rule configuring module 230, configured to configure multiple status policies before and after the API call request is responded, and respond the status policies with different status code processing functions in a combined manner.

And a buried point rule generating module 240, configured to obtain the status code rule, and generate the buried point rule based on the status code rule.

API configuration, URL configuration, state code rules, embedded point rules and the like are extracted independently, unified request state code processing is carried out, the unified request state code processing is packaged into a rule engine, when the unified request state code processing method is used, a user-defined configuration rule, the state code rules, the embedded point rules and the like form a merging rule, after an API call request of a front end is received, an API processing function can be automatically generated according to the configured merging rule, developers do not need to repeatedly process the same scene, manpower waste is avoided, updating and maintaining cost is reduced, and the problems that the strongly-coupled API updating and maintaining cost is high and the API is repeatedly developed in the prior art are solved.

An embodiment of the present application further provides an electronic device, where the electronic device includes a memory and a processor, the memory is used to store a computer program, and the processor runs the computer program to enable the electronic device to execute the request status code processing method according to embodiment 1.

An embodiment of the present application further provides a readable storage medium, where computer program instructions are stored, and when the computer program instructions are read and executed by a processor, the method for processing a request status code according to embodiment 1 is performed.

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

In addition, functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

The functions may be stored in a computer-readable storage medium if they are implemented in the form of software functional modules and sold or used as separate products. Based on such understanding, the technical solution of the present application or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk, and various media capable of storing program codes.

The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

It should be noted that, in this document, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising a," "8230," "8230," or "comprising" does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.

Claims (10)

1. A method for processing request status codes, the method comprising:

responding to the API call request, and acquiring a user-defined configuration rule;

combining the user-defined configuration rule with a preset embedded point rule and a preset state code rule in a rule engine to generate a synthesis rule;

and generating an API processing function based on the synthesis rule, the configuration file and the state code generation template.

2. The method for processing request status code according to claim 1, wherein before the step of obtaining the user-defined configuration rule, the method comprises:

and performing API configuration based on JSON data, wherein the configuration comprises an API function name, whether the API function name is an asynchronous function, whether the cache is enabled, and whether the execution track is recorded through a felog.

3. The method of claim 1, wherein before the step of obtaining the user-defined configuration rule, the method comprises:

and performing URL configuration based on JSON data, wherein the configuration comprises an interface address, a domain name placeholder, interface description information, a reference type, a default value and a return value.

4. The method of claim 1, wherein prior to the step of merging the user-defined configuration rules with the fixed point rules and state code rules preset in the rules engine, the method comprises configuring the state code rules:

configuring multiple state strategies before and after the API call request response, and responding the state strategies by different state code processing functions in a combined mode.

5. The method of claim 1, wherein prior to the step of merging the user-defined configuration rules with the fixed-point rule and the state code rule preset in the rule engine, the method comprises generating a fixed-point rule:

and acquiring a state code rule, and generating a buried point rule based on the state code rule.

6. A request status code processing apparatus, the apparatus comprising:

the user rule obtaining module is used for responding to the API call request and obtaining a user-defined configuration rule;

the synthesis module is used for combining the user-defined configuration rule with a preset embedded point rule and a preset state code rule in a rule engine to generate a synthesis rule;

and the function generation module is used for generating an API processing function based on the synthesis rule, the configuration file and the state code generation template.

7. The request status code processing apparatus according to claim 6, wherein said apparatus further comprises:

and the API configuration module is used for carrying out API configuration based on JSON data, and the configuration comprises the name of an API function, whether the API function is an asynchronous function, whether the cache is enabled and whether an execution track is recorded through a felog.

8. The request status code processing apparatus according to claim 6, wherein said apparatus further comprises:

and the URL configuration module is used for carrying out URL configuration based on JSON data, and the configuration comprises an interface address, a domain name placeholder, interface description information, a reference type, a default value and a return value.

9. An electronic device, characterized in that the electronic device comprises a memory for storing a computer program and a processor for executing the computer program to cause the electronic device to perform the request status code processing method according to any one of claims 1 to 5.

10. A readable storage medium having stored therein computer program instructions which, when read and executed by a processor, perform the request state code processing method of any one of claims 1 to 5.

Images