Routing to Controllers
By default, Sails will create a blueprint action route for each action in a controller, so that a
GET request to
/:controllerIdentity/:nameOfAction will trigger the action. If the example controller in the previous section was saved as
api/controllers/SayController.js, then the
/say/bye routes would be made available by default whenever the app was lifted. If the controller was saved under the subfolder
/we, then the routes would be
/we/say/bye. See the blueprints documentation for more information about Sails’ automatic route binding.
Besides the default routing, Sails allows you to manually bind routes to controller actions using the
config/routes.js file. Some examples of when you might want to use explicit routes are:
- When you want to use separate actions to handle the same route path, based on the HTTP method (aka verb). The aforementioned action blueprint routes bind all request methods for a path to a given action, including
- When you want an action to be available at a custom URL (e.g.
POST /signup, or a "vanity URL" like
- When you want to set up additional options for how the route should be handled (e.g. special CORS configuration)
To manually bind a route to a controller action in the
config/routes.js file, you can use the HTTP verb and path (i.e. the route address) as the key, and the controller name +
. + action name as the value (i.e. the route target).
For example, the following manual route will cause your app to trigger the
makeIt() action in
api/controllers/SandwichController.js whenever it receives a POST request to
'POST /make/a/sandwich': 'SandwichController.makeIt'
For controller files saved in subfolders, the subfolder is part of the controller identity:
This will cause the
api/controllers/stuff/things/HomeworkController.jsto be triggered whenever
A full discussion of manual routing is out of the scope of this doc--please see the routes documentation for a full overview of the available options.