But not anymore. I use routing constraints commonly to add security and cleanliness to projects I work on, and I think that more programmers using rails can benefit from this tool.

Introducing Routing Constraints

Routing constraints are checks written around routes that will clean and validate information before even hitting a controller action. The key word here is before. Before this external data can touch behavior in your controllers, and subsequently your persistence layers, it already gets vetted. This opens up a lot of flexibility and security to our controllers, and can keep us from writing more boilerplate than we normally would.

What about some use cases?

I learn the best from examples -- from context and code. I’ve chosen some of what I thought are the most valuable and enlightening use cases that highlight effective and efficient constraint usage.

1. Security vulnerabilities and data type validation

Lately the rails community had a flurry of excitement with the uncovering of a number of security holes for sql injection.
Commonly-used frameworks are usually secure, but issues like this occur when the data directly submitted to a database query can be anything from the params. We’ve seen that its difficult to protect from literally everything. And you don’t need to if you set constraints at the route level.
Our route looks like this:

would wipe out the user table (this security issue has already been addressed in newer versions of rails).
If we are worried about users injecting something harmful through the params -- whatever that may be -- changing our route like this will prevent this from happening:

1get'user/:id'=>'user#show',constraint:{id:/\d+/}

If it doesn’t pass the integer test, we don’t hit the action. Problem solved. No need to have to_s or to_i in our actions and no need to worry about writing extra checks to plan for security holes.
Constraints are best used for basic data validation, and not for more complicated business rules. But for doing basic data validation and url protection, a few routing constraints can remove a lot of duplicated type validation and make your system more secure.

Constraints are easy to incrementally implement in your application

I think these use cases are enough to show how constraints promote less boilerplate, less worry about security, better encapsulation, and more control over your system from an abstracted layer.

Start by looking for shared validation functions, or those pesky ‘to_i’ and ‘to_s’ functions that commonly append themselves to param calls in actions. Constraints are low-cost in terms of time and effort for implementation and yield nice results for the health of your system.