Nested resources in IBM WebSphere sMash

Using nested resources

By default, resources in WebSphere sMash are presumed to be flat in terms of the URL pattern. Resources can be nested by specifying the valid relationships in a bonding file associated with the resource handler. For example, the bonding file associated with app/resources/employees.groovy would be app/resources/employees.bnd. If the bonding file is found, then the content specifies the valid access patterns for invoking the resource

For example, consider an example of nested resources:

/resources/people/<peopleId>/accounts/<accountsId>

Although it is possible to handle this request with the people resource handler and pathInfo, the implementation may be better factored by implementing the account resource directly as shown in the following example:

<apphome>
+ app/
  + resources/
    - people.groovy
    - accounts.groovy
    - accounts.bnd

accounts.bnd is a text file that contains one nesting pattern per line. The nesting pattern is a slash-delimited list of resource names. The hash mark (#) indicates a comment line.

Example: bonding file

# Nesting relationships for the account resource
people/accounts

When invoked as a nested resource, member ids of parent resources are provided to the target resource handler as query parameters named as <collectionName>Id. The following table provides an example.

Note that the patterns in a bonding file are the only ways to invoke that resource. In the above example, a request for /resources/accounts would result in a 404 because accounts does not appear as a pattern. To also support /resources/accounts, then the bonding file could be changed to:

# Nesting relationships for the account resource
accounts
people/accounts

Hierarchies of flat resources

Another pattern of RESTful design uses flat resources and query parameters to implement hierarchical relationships.

The example of nested resources:

/resources/people/<peopleId>/accounts/<accountsId>

could be recast with flat resources and query parameters as:

/resources/accounts/<accountsId>?people=<peopleId>

Because WebSphere sMash provides member IDs of parent collections as query parameters in the nested resources pattern, just as you would receive in this pattern, the handler implementation for a given resource could be identical for both patterns.

The following table provides an example of this pattern: