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 the 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 setting this disable field using a spring property, so you can enable different behaviors in development and production servers. This allows developers to try different selectors in a sandbox, then add them to the alias properties file and roll it out to production without having to push a new build.

You can even 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/favoriteArtists/1.json