Question

In play framework 1, you could use in the routes file something like this (check documentation at http://www.playframework.org/documentation/1.2.5/routes#syntax)

GET     /clients/?       Clients.index

so that the route will match /api/clients and also /api/clients/

How can I achieve the same in play framework 2?

Answer 1

From SEO point of view the same link with trailing slash is other one than link without it. It is highly recommended to always use one schema (trailed or un-trailed links).

Although there are different schools which one is better the most important is to make a 301 redirect from ‘wrong’ URL to the correct. You can achieve it quite easy in Play with a ‘Dynamic part spanning several /‘.

Personally I prefer un-trailed version, maybe because implementing it in the Play is just like writing few simple lines. Add to your routes file this rule, somewhere at the beginning (keep the slash – it’s important as it’s NOT considered as next slash in the spanning-group, and allows to match trailed URL’s easily):

GET  /*path/  controllers.Application.untrail(path: String)

then you can just make a redirect in the controller – to the param, so it will be without the slash at the end:

Java

public static Result untrail(String path) {
   return movedPermanently("/" + path);
}

Scala

def untrail(path: String) = Action { 
  MovedPermanently("/" + path)
}

Until now, all routes ending with the slash will be redirected to the un-trailed version. Easy 🙂

Of course it’s highly recommended to use reverse router for generating correct URL’s – to minimalize redundant redirects. Also if you’re hardcoding the URL somewhere (ie. in some JS or in external application) it’s also better to write correct ones instead converting them every time. If you’re planning to publish some public API make a note in documentation, which pattern does your application prefer, so developers will be warned and (maybe) will prepare correct calls.

What’s more – it most important for GET routes as they are a subject to manipulation from the client’s side. While using POST, PUT, DELETE and others you don’t need (or rather, you should’t) to care about redirects as they can not be changed by the user and in that way you need to remember which way you choose. In case of wrong call ie. for POST, just return a 404 error – so the developer of the 3-rd part application will be obligated to use correct endings.