The full list of the supported attributes for each param are listed below:

The supported keys of the validationFailureTexts are:

So, as an example:

In such case if the submitted value for the "age" is under 18 (let's say 17) then on the "errors" array of the response there will be the text "Sorry, you must be at least 18 years old". If the key "min" was missing from the "validationFailureTexts" object (of if the "validationFailureTexts" was missing at all on the field's definition), the error text that would be included on the errors array would be the default: "Age must be greater or equal to 18. 17 provided." Finally, in the case that there was the "humanReadable" key missing from the field's definition, then the error text would be: "user_age must be greater or equal to 18. 17 provided."

You might have noticed the term "Tree" in the name of the "Routes Tree Configuration File". Before further analysing the way we can define your routes in here, it's good to mention a few things regarding its concept. In an application there might be routes of the same url (e.g. /a/b) but of different types (e.g. GET, POST). Also, in an application there might be routes that do something and also subroutes of it that do something else. For example, there might be the route /a/b and also the route /a/b/c. The way the routes are defined on the Routes Tree Definition File respect both of the above facts. On any given path you can separately define the various supported call types and then you can continue deeper defining the supported subroutes of it. In the specific example here's a possible / valid Routes Tree Configuration File:

In general, the tree that we are defining here consists of paths and endpoints. Everything starts on the "routes" parameter of the returned object. "a" represents a path, the path "/a". This path has subRoutes, like "/a/b". So, we define these subroutes on the "subRoutes" parameter of it. "b" is a path itself as well. Following the object's structure, is obvious that it represents the path "/a/b". A path might have (or might not have) endpoints. For example the path "/a" does not have any endpoints. Though, path "/a/b" has get and post endpoints. The endpoints are defined by the use of the corresponding key (one of "get", "post", "put", "delete"). The endpoints are the "leafs" of this tree while the paths act as the branches. A branch can have sub-branches and leafs. A leaf cannot have neither sub-branches nor sub-leafs, and that's we call then "endpoints". Within the "subRoutes" parameter of any path we can only define paths. On any endpoint we can define the fields that we're expecting. Here's a table with all the supported attributes of each element:

As you can see, on the GET "/a/b" endpoint we have defined three fields:

The Error Handling Configuration File exports an object. Each object key represents the "type" of the error. So, in our example, if an undefined error gets triggered by the app, our application will log it, it will write to the log file the text "Unresolved error code" and the client will receive a 500 code along with the body "ErrCode: 1 - There was an error fulfilling your request at the moment. Please try again in a while". Let's dive deeper and see which attributes are supported for each error type defined on this file.

In order for this part of code to work you must have the "next" function available. Fot those who are not that familiar with "next" function, please have a look here. Once you trigger this event the rest is on Express Happiness to take care of, according to the Error Handling Configuration File.

var functions = [];

functions['route-alias-1'] = adminFunctions.doSomething; functions['route-alias-2'] = userFunctions.doSomethingElse;

exports.functions = functions; It's just a mapping of all controller functions to the routes. As you can see from the example snippet 12, the Controller Functions File should export an array. An associative array the keys of which are alias name of each route and the values the corresponding controller functions of them. The controller function for each endpoint is in the exact same format as a simple controller function that you would define if you used express without Express Happiness. That is:

var eh = new expressHappiness(app, router, { mockData:{ enable: true, folder: '/path/to/mockdatafolder', global: true }, reusableFieldsFile: '/path/to/reusableFields.js', errorFile: '/path/to/errors.log', errorsConfigurationFile: '/path/to/conf/errors.js', apiConfigurationFile: 'path/to/conf/restConf.js', controllersFile: '/path/to/controllerFunctions.js' });

eh.generate('/v1', { 'userAccess':[middlewareA, middlewareB], 'adminAccess':[middlewareC, middlewareD], 'eh-allRoutes':[middlewareX] }, { 'userAccess':[middlewareA, middlewareB], 'adminAccess':[middlewareC, middlewareD], 'eh-allRoutes':[middlewareX] } );

First thing to do is to create a new Express Happiness instance. This is done by calling "new expressHappiness" function. This function takes three parameters:

After creating the EH instance we call the "generate" function of it. The "generate" function takes three parameters:

The form of our middlewares should be the typical middleware form of express: function(req, res, next).