Aliases

In production environments it's recommended to hide the selectors behind aliases for performance and security reasons.

To do this, create a properties file, say selectorAlias.properties and put it in your classpath.

Then add a configuration entry via spring to enable it:

<bean id="aliasSelectorResolver" class="org.skyscreamer.yoga.selector.parser.DynamicPropertyResolver">
    <property name="propertyFile" value="classpath:selectorAlias.properties" />
</bean>

In the file you define the alias with a simple $alias=selector syntax. By convention, each alias must start with a $. For example:

$userFavoriteArtists=id,name,favoriteArtists(id,name)

Now, users are able to invoke the alias:

GET /user/1.json?selector=$userFavoriteArtists

this is equivalent to:

GET /user/1.json?selector=id,name,favoriteArtists(id,name)

You can always disable non-aliased selectors by setting a field in your selector parser bean definition. For example:

<bean id="selectorParser" class="org.skyscreamer.yoga.selector.parser.GDataSelectorParser">
    <property name="disableExplicitSelectors" value="true" />
</bean>

We recommend a best practice of using Spring 3.1 Environment Profiles to enable different behaviors in development and production. In such a setup, the workflow looks like this:

1. Developers try different selectors in a sandbox envirionment.
2. When they find the selector for what they need, they add it to the alias properties file.
3. An admin deploys the new alias file to production, without having to create a new build or expose the raw selector.

You can go one step farther and hide these aliases behind more RESTful-looking URLs using a filter like URLRewrite so the same URL looks something like:

GET /user/1/favoriteArtists.json