Edit Page

Routes

Overview

The most basic feature of any web application is the ability to interpret a request sent to a URL, then send back a response. In order to do this, your application has to be able to distinguish one URL from another.

Like most web frameworks, Sails provides a router: a mechanism for mapping URLs to controllers and views. Routes are rules that tell Sails what to do when faced with an incoming request. There are two main types of routes in Sails: custom (or "explicit") and automatic (or "implicit").

Custom Routes

Sails lets you design your app's URLs in any way you like- there are no framework restrictions.

Every Sails project comes with config/routes.js, a simple Node.js module that exports an object of custom, or "explicit" routes. For example, this routes.js file defines six routes; some of them point to a controller's action, while others route directly to a view.

// config/routes.js
module.exports.routes = {
  'get /signup': { view: 'conversion/signup' },
  'post /signup': 'AuthController.processSignup',
  'get /login': { view: 'portal/login' },
  'post /login': 'AuthController.processLogin',
  '/logout': 'AuthController.logout',
  'get /me': 'UserController.profile'
}

Each route consists of an address (on the left, e.g. 'get /me') and a target (on the right, e.g. 'UserController.profile') The address is a URL path and (optionally) a specific HTTP method. The target can be defined a number of different ways (see the expanded concepts section on the subject), but the two different syntaxes above are the most common. When Sails receives an incoming request, it checks the address of all custom routes for matches. If a matching route is found, the request is then passed to its target.

For example, we might read 'get /me': 'UserController.profile' as:

"Hey Sails, when you receive a GET request to http://mydomain.com/me, run the profile action of UserController, would'ya?"

What if I want to change the view layout within the route itself? No problem we could:

'get /privacy': {
    view: 'users/privacy',
    locals: {
      layout: 'users'
    }
  },

Notes

  • Just because a request matches a route address doesn't necessarily mean it will be passed to that route's target directly. For instance, HTTP requests will usually pass through some middleware first. And if the route points to a controller action, the request will need to pass through any configured policies first. Finally, there are a few special route options which allow a route to be "skipped" for certain kinds of requests.
  • The router can also programmatically bind a route to any valid route target, including canonical Node middleware functions (i.e. function (req, res, next) {}). However, you should always use the conventional route target syntax when possible- it streamlines development, simplifies training, and makes your app more maintainable.

Automatic Routes

In addition to your custom routes, Sails binds many routes for you automatically. If a URL doesn't match a custom route, it may match one of the automatic routes and still generate a response. The main types of automatic routes in Sails are:

  • Blueprint routes, which provide your controllers and models with a full REST API.
  • Assets, such as images, Javascript and stylesheet files.
  • CSRF, if turned on, provides a /csrfToken route to your app that can be used to retrieve the CSRF token.

Supported Protocols

The Sails router is "protocol-agnostic"; it knows how to handle both HTTP requests and messages sent via WebSockets. It accomplishes this by listening for Socket.io messages sent to reserved event handlers in a simple format, called JWR (JSON-WebSocket Request/Response). This specification is implemented and available out of the box in the client-side socket SDK.

Notes

  • Advanced users may opt to circumvent the router entirely and send low-level, completely customizable WebSocket messages directly to the underlying Socket.io server. You can bind socket events directly in your app's onConnect function (located in config/sockets.js.) But bear in mind that, in most cases, you are better off leveraging the request interpreter for socket communication - maintaining consistent routes across HTTP and WebSockets helps keep your app maintainable.

Is something missing?

If you notice something we've missed or could be improved on, please follow this link and submit a pull request to the sails-docs repo. Once we merge it, the changes will be reflected on the website the next time it is deployed.

Sails logo
  • Home
  • Get started
  • Support
  • Documentation
  • Documentation

For a better experience on sailsjs.com, update your browser.

Documentation

Reference Concepts App structure | Upgrading Contribution guide | Tutorials More

Concepts

  • Assets
    • Default Tasks
    • Disabling Grunt
    • Task Automation
  • Blueprints
    • Blueprint Actions
    • Blueprint Routes
  • Configuration
    • The local.js file
    • Using `.sailsrc` Files
  • Controllers
    • Generating Controllers
    • Routing to Controllers
  • Custom Responses
    • Adding a Custom Response
    • Default Responses
  • Deployment
    • FAQ
    • Hosting
    • Scaling
  • Extending Sails
    • Adapters
      • Available Adapters
      • Custom Adapters
    • Generators
      • Available Generators
      • Custom Generators
    • Hooks
      • Hook Specification
        • .configure()
        • .defaults
        • .initialize()
        • .routes
      • Installable Hooks
      • Project Hooks
      • Using Hooks
  • File Uploads
    • Uploading to GridFS
    • Uploading to S3
  • Globals
    • Disabling Globals
  • Internationalization
    • Locales
    • Translating Dynamic Content
  • Logging
    • Custom log messages
  • Middleware
    • Conventional Defaults
  • Models and ORM
    • Associations
      • Dominance
      • Many-to-Many
      • One Way Association
      • One-to-Many
      • One-to-One
      • Through Associations
    • Attributes
    • Lifecycle callbacks
    • Model Settings
    • Models
    • Query Language
    • Validations
  • Policies
    • Sails + Passport
  • Programmatic Usage
    • Tips and Tricks
  • Realtime
    • Multi-server environments
    • On the client
    • On the server
  • Routes
    • Custom Routes
    • URL Slugs
  • Security
    • Clickjacking
    • Content Security Policy
    • CORS
    • CSRF
    • DDOS
    • P3P
    • Socket Hijacking
    • Strict Transport Security
    • XSS
  • Services
    • Creating a Service
  • Sessions
  • Testing
  • Views
    • Layouts
    • Locals
    • Partials
    • View Engines

Built with Love

The Sails framework is maintained by a web & mobile studio in Austin, TX, with the help of our contributors. We created Sails in 2012 to assist us on Node.js projects. Naturally we open-sourced it. We hope it makes your life a little bit easier!

Sails:
  • What is Sails?
  • Treeline IDE
  • Contribute
  • Logos/artwork
About:
  • The Sails Company
  • Security
  • News
  • Legal
Help:
  • Get started
  • Documentation
  • Docs
  • Enterprise
  • Hire us

© 2012-2018 The Sails Company. 
The Sails framework is free and open-source under the MIT License.