CN110825357A - Web server frame method for generating request route according to source file directory structure - Google Patents
Web server frame method for generating request route according to source file directory structure Download PDFInfo
- Publication number
- CN110825357A CN110825357A CN201911120483.8A CN201911120483A CN110825357A CN 110825357 A CN110825357 A CN 110825357A CN 201911120483 A CN201911120483 A CN 201911120483A CN 110825357 A CN110825357 A CN 110825357A
- Authority
- CN
- China
- Prior art keywords
- source file
- request
- routing
- path
- directory structure
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 34
- 238000012545 processing Methods 0.000 claims abstract description 35
- 238000013499 data model Methods 0.000 claims abstract description 14
- 238000004806 packaging method and process Methods 0.000 claims abstract description 5
- 230000008569 process Effects 0.000 claims description 7
- 230000004044 response Effects 0.000 claims description 6
- 238000011161 development Methods 0.000 description 11
- 230000006870 function Effects 0.000 description 9
- 239000008186 active pharmaceutical agent Substances 0.000 description 5
- 238000012423 maintenance Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000007547 defect Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 239000000243 solution Substances 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/73—Program documentation
Abstract
The invention relates to a Web application technology, in particular to a method for generating a Web server framework of a request route according to a source file directory structure, which comprises the following steps: the method comprises the following steps: establishing a directory structure of the project; step two: storing a routing processing source file and a request data description file under the project catalog structure/routes, storing a service layer module definition source file under the services, storing a data model definition source file under the models, and storing a utility tool module source file under the utilities; step three: the definition of the routing is that the path where the routing processing source file is located is used as a request routing by packaging Express, and the file name of the path is used as a request method; step four: the path of the route processing source file, namely the route which needs to be processed, represents the path parameter by the folder name enclosed by brackets; the name of the routing processing source file is a request method, and the output is a function.
Description
Technical Field
The invention relates to a Web application technology, in particular to a method for generating a Web server framework of a request route according to a source file directory structure.
Background
When developing Web applications, routing design and configuration are the first work to be performed in Web application development, and currently, when developing Web applications using node. For large-scale Web applications, as development work advances and the application scale grows, the following problems will emerge gradually: 1. routing configuration source files are too bloated; 2. multiple people edit the routing configuration source file easily to cause conflict; 3. duplicate routing rules are not easily discovered; 4. the relationship between the route and the service realization source file is not intuitive, and the maintenance is not convenient;
nowadays, a Web application design mode is mainly SaaS, an API document is indispensable, how to keep the content of the API document consistent with code logic (what is a request path, what parameters, what requirements of each parameter, and what data is returned) and whether to automatically generate the API document according to the code are also a problem that a Web framework should solve. However, the main flow framework only provides a middleware mechanism, and to achieve the above goal, a developer must implement corresponding middleware and configure each route.
In addition, business logic must be layered in the Web application development process to form different types of modules, such as controllers, services, data models, utility tools, and the like, and the restriction and calling modes depending among the different types of modules are also problems to be considered in the large-scale Web application development process. For example, according to the Web development specification, cross-level calling between modules is not required, which requires that a set of rules be defined to distinguish module types and restrict calling between modules through a framework. For another example, in the process of developing an enterprise-level application, a module in node. js is not generally released as an NPM package, which needs to be introduced through a specified path, which not only reduces the readability of the code (which may generate multiple layers of relative paths), but also is not beneficial to the maintenance of the project (for example, moving one file may affect multiple codes depending on the file).
Disclosure of Invention
The invention aims to solve the technical defects, and provides a Web server framework method for generating a request route according to a source file directory structure, which can be used for packaging and integrating a plurality of functional modules, standardizes the development of Web application by defining a set of simple rules, and improves the development efficiency of a multi-user collaborative development mode.
In order to solve the technical problems, the technical scheme adopted by the invention is as follows: a method for generating a Web server framework for request routing according to a source file directory structure comprises the following steps:
the method comprises the following steps: establishing a directory structure of the project;
step two: storing a routing processing source file and a request data description file under the project catalog structure/routes, storing a service layer module definition source file under the services, storing a data model definition source file under the models, and storing a utility tool module source file under the utilities;
step three: the definition of the routing is that the path where the routing processing source file is located is used as a request routing by packaging Express, and the file name of the path is used as a request method;
step four: the path of the route processing source file, namely the route which needs to be processed, represents the path parameter by the folder name enclosed by brackets; the name of a routing processing source file is a request method, and the output is a function;
step five: setting a description file with the same name as the routing processing source file and with the json extension name under the path of the routing processing source file to define the name and the description of the routing, the form of the receivable client request data and the form of the response data;
step six: before the client request is routed to the processing logic defined by the routing processing source file, the request data is checked according to the description file, and if the request data does not meet the requirements, an error is returned;
step seven: when the Web application is started, the framework automatically loads modules under each path, generates indexes according to file names and registers the indexes to respective namespaces;
preferably, the description language of the form of the Request data and the response data is JSON Schema, which specifies what Path Parameters (Path Parameters), Query Parameters (Query Parameters) and the structure of the Request data (Request Body) are required, the type of the Parameters and whether the requirements are necessary.
Preferably, the indexing and registering of step seven may adopt: the module defined by/services/user.js will be referred to as the service layer module and named UserService, the module defined by/models/user.js will be referred to as the data model and named UserModel, and the module defined by/files/crypto.js will be referred to as the utility and named CryptoUtil.
Preferably, the output of the source file is a function, the parameter is a list of names of modules depended on, and the return value is an object of the defined module.
Preferably, dependencies between modules need to follow the following requirements, otherwise the framework will throw exceptions when the Web application starts: 1. module hierarchy: routing process → service → data model; 2. the modules cannot be depended on by the same level and cannot be depended on by different levels.
The invention achieves the following beneficial effects: the Web server framework method for generating the request route according to the source file directory structure defines the route through the file path structure, so that the route definition is clear and visual, and the problems of single file overstaffed caused by using configuration files and difficult maintenance for multiple persons are avoided; the API document is generated according to the codes, the consistency of the codes and the document is ensured, and the automatically generated document format is uniform; the mode of dependent injection is used to depend on other modules, so that a module path is prevented from being specified through hard codes, and the codes are easy to maintain; the division of module service layers and the dependency relationship among the modules are standardized, so that the engineering structure is clear, and the multiplexing of the modules is facilitated.
Drawings
FIG. 1 is an example of an engineering structure of a Web application of the present invention.
Fig. 2 is a loading flow of modules when an application is started.
Detailed Description
The invention is further described below with reference to the accompanying drawings. The following examples are only for illustrating the technical solutions of the present invention more clearly, and the protection scope of the present invention is not limited thereby.
The framework encapsulates and integrates a plurality of functional modules, and the development of Web application is standardized by defining a set of simple rules, so that the development efficiency of a multi-person collaborative development mode is improved.
First defined is the directory structure of the project. The method comprises the steps of storing a routing processing source file and a request data description file under routes, storing a service layer module definition source file under services, storing a data model definition source file under models, and storing a utility tool module source file under utilils.
The definition of the routing is that the path where the routing processing source file is located is used as a request routing and the file name is used as a request method by packaging Express, so that routing configuration is not required to be concentrated in one file, and the possibility of repeated definition is reduced to a certain extent. For example,/routes/users/{ userId }/orders/get.js source files will be used to process GET/users/000001/orders requests. The path of the routing processing source file, namely the route which needs to be processed by the routing processing source file, and the folder name enclosed in parentheses represents the path parameter. The name of the routing processing source file is a request method (such as get, post, put, patch, delete, etc.), and the output is a function (i.e., routing processing logic).
A description file with the same name as a routing processing source file and with the json extension is arranged in a path where the routing processing source file is located, so that the name and the description of the routing, the form of receivable client request data and the form of response data are defined. The request data and the response data are described in the form of JSON Schema, which specifies what Path Parameters (Path Parameters), Query Parameters (Query Parameters) and the structure of the request data (RequestBody) are required, what the types of the Parameters are, and whether the requirements are required. Before the client request is routed to the processing logic defined by the routing processing source file, the request data is checked against the description file, and if not, an error is returned. The framework also provides commands for generating API documents from these description files.
When the Web application is started, the framework automatically loads the modules under each path, generates indexes according to file names and registers the indexes to respective namespaces. For example, the module defined by/services/user.js will be referred to as a service layer module and named UserService, the module defined by/models/user.js will be referred to as a data model and named UserModel, and the module defined by/utilis/crypto.js will be referred to as a utility and named CryptoUtil. The output of the source files is a function, the parameters are a list of names of the modules depended on, and the return values are objects of the defined modules, so that a factory mode for injecting the required modules according to the names of the modules in a dependent mode is realized.
Js, for example, defines a function for generating user data manipulation service modules that rely on user data models (to manipulate user data in a database) and data encryption utilities (to encrypt passwords). The content of the file is therefore:
module. ports = function (user model, CryptoUtil) { return {/, definition of the method provided by the module };
after the file is loaded, the framework acquires the registered modules according to the parameter names of the functions, executes the functions by using the modules as parameters, and registers the return results in the name space of the service module.
The dependencies between modules need to follow the following requirements, otherwise the framework will throw exceptions when the Web application starts: module hierarchy: routing process → service → data model; 1. the modules cannot be depended on at the same level or at different levels; 2. all modules may depend on the utility.
In fig. 1, package json is a project definition file of node js, and defines project information, executable scripts, and dependencies on the framework and third-party modules. Js and/models/order define a user data model and an order data model, respectively, for implementing operations on database data of users and orders. Js and/services/order defines user service and order service, respectively, for implementing functions of user query and order creation and query. Js defines a security-related utility for encrypting user passwords. The routing rules and definition of processing logic are stored/routes. When the application is started, the framework loads the service modules in sequence according to the flow of fig. 2.
After starting HTTP service, the client calls a corresponding interface, the server forwards the request to a corresponding routing processing logic for processing according to the path of the client request, the request data is checked according to the request data definition before processing, if the request data fails to pass the check, an error is returned, otherwise, the data of the client bar is processed according to the routing processing logic.
The above is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, several modifications and variations can be made without departing from the technical principle of the present invention, and these modifications and variations should also be regarded as the protection scope of the present invention.
Claims (5)
1. A method for generating a Web server framework for request routing based on a source file directory structure, the method comprising: the method comprises the following steps:
the method comprises the following steps: establishing a directory structure of the project;
step two: storing a routing processing source file and a request data description file under the project catalog structure/routes, storing a service layer module definition source file under the services, storing a data model definition source file under the models, and storing a utility tool module source file under the utilities;
step three: the definition of the routing is that the path where the routing processing source file is located is used as a request routing by packaging Express, and the file name of the path is used as a request method;
step four: the path of the route processing source file, namely the route which needs to be processed, represents the path parameter by the folder name enclosed by brackets; the name of a routing processing source file is a request method, and the output is a function;
step five: setting a description file with the same name as the routing processing source file and with the json extension name under the path of the routing processing source file to define the name and the description of the routing, the form of the receivable client request data and the form of the response data;
step six: before the client request is routed to the processing logic defined by the routing processing source file, the request data is checked according to the description file, and if the request data does not meet the requirements, an error is returned;
step seven: when the Web application is started, the framework automatically loads the modules under each path, generates indexes according to file names and registers the indexes to respective namespaces.
2. The method of claim 1 for generating a Web server framework for request routing based on a source file directory structure, wherein: the Request data and the response data are described in the form of JSON Schema, which specifies what Path Parameters (Path Parameters), Query Parameters (Query Parameters) and the structure of the Request data (Request Body) are required, the type of Parameters and whether the requirements are necessary.
3. The method of claim 1 for generating a Web server framework for request routing based on a source file directory structure, wherein: the indexing and registration of the seventh step may adopt: the module defined by/services/user.js will be referred to as the service layer module and named UserService, the module defined by/models/user.js will be referred to as the data model and named UserModel, and the module defined by/files/crypto.js will be referred to as the utility and named CryptoUtil.
4. The method of claim 3 for generating a Web server framework for request routing based on a source file directory structure, wherein: the output of the source file is a function, the parameter is a list of names of the modules depended on, and the return value is an object of the defined module.
5. The method of claim 1 for generating a Web server framework for request routing based on a source file directory structure, wherein: the dependencies between modules need to follow the following requirements, otherwise the framework will throw exceptions when the Web application starts: 1. module hierarchy: routing process → service → data model; 2. the modules cannot be depended on by the same level and cannot be depended on by different levels.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911120483.8A CN110825357A (en) | 2019-11-15 | 2019-11-15 | Web server frame method for generating request route according to source file directory structure |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911120483.8A CN110825357A (en) | 2019-11-15 | 2019-11-15 | Web server frame method for generating request route according to source file directory structure |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN110825357A true CN110825357A (en) | 2020-02-21 |
Family
ID=69556014
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911120483.8A Pending CN110825357A (en) | 2019-11-15 | 2019-11-15 | Web server frame method for generating request route according to source file directory structure |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110825357A (en) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050160153A1 (en) * | 2004-01-21 | 2005-07-21 | International Business Machines Corp. | Publishing multipart WSDL files to URL |
| CN108390773A (en) * | 2018-02-02 | 2018-08-10 | 上海汉得信息技术股份有限公司 | A kind of method and apparatus of dynamic routing for scaffold |
| CN108549545A (en) * | 2018-04-20 | 2018-09-18 | 武汉极意网络科技有限公司 | A kind of project organization method and system based on tornado frames |
-
2019
- 2019-11-15 CN CN201911120483.8A patent/CN110825357A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050160153A1 (en) * | 2004-01-21 | 2005-07-21 | International Business Machines Corp. | Publishing multipart WSDL files to URL |
| CN108390773A (en) * | 2018-02-02 | 2018-08-10 | 上海汉得信息技术股份有限公司 | A kind of method and apparatus of dynamic routing for scaffold |
| CN108549545A (en) * | 2018-04-20 | 2018-09-18 | 武汉极意网络科技有限公司 | A kind of project organization method and system based on tornado frames |
Non-Patent Citations (2)
| Title |
|---|
| NISHTHA HOODA 等: "MCTOPE Ensemble Machine Learning Framework: A Case Study of Routing Protocol Prediction" * |
| 刘黎志;: "基于SingalR的Web实时应用程序框架设计" * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7076819B2 (en) | Move and store encrypted user data | |
| US11163791B2 (en) | Transformation configuration in instance data replication with bi-directional replication support | |
| US8146099B2 (en) | Service-oriented pipeline based architecture | |
| CN112748908B (en) | Method and device for developing Restful service based on SSM framework | |
| CN112486547B (en) | Application program updating method and device under multi-tenant scene and electronic equipment | |
| CN109669976B (en) | ETL-based data service method and device | |
| US20130275958A1 (en) | Automatic identification of services | |
| CN101382893B (en) | On-line assembling method for component based on Web service | |
| US8386608B1 (en) | Service scripting framework | |
| CN111443901B (en) | Java reflection-based service expansion method and device | |
| US20190005228A1 (en) | Trusted and untrusted code execution in a workflow | |
| CN112199164A (en) | Method for ensuring container mirror image consistency | |
| CN114254606A (en) | Microservice framework model | |
| US20190095840A1 (en) | System and method for implementing a federated forecasting framework | |
| CN111966718B (en) | System and method for data propagation tracking of application systems | |
| CN116982029A (en) | Hosting event-based applications | |
| CN112947992A (en) | Method and device for managing code version | |
| CN110825357A (en) | Web server frame method for generating request route according to source file directory structure | |
| CN114296789B (en) | Business processing method, device, equipment and storage medium based on full-process configuration | |
| CN114676418A (en) | Operation request processing method, device, equipment, storage medium and program product | |
| CN109117152B (en) | Service generation system and method | |
| TW201448544A (en) | Message exchange via generic TLV generator and parser | |
| CN113342399A (en) | Application structure configuration method and device and readable storage medium | |
| US9596292B1 (en) | Client-side scripts in a service-oriented API environment | |
| CN117527895A (en) | HTTP request processing method and system based on AOP |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20200221 |
|
| WD01 | Invention patent application deemed withdrawn after publication |