Handling The Handler
Every resource needs a handler to perform the RESTful web services. By convention, WebSphere sMash will look for a file with the same name (as the resource model ) in the app/resources directory, except with a .groovy file extention rather than .json.
But I don’t want to script custom handlers for each resource. So, I can write a single handler script and assign it to my resources by configuring the zero.config file. Or, I can continue having separate handler files for each resource but use the same generic (write-one-time) code in each. sMash uses the second approach in their published examples. If you want to let sMash implicitly manage the persistence and retrieval, for example, you can put the same single line of code in each handler, i.e. ZRM.delegate().
On principal, I prefer the first approach. However, doing that forfeits some of intelligence you get for free with the separate handler files. Doing it the second way, you only need to implement methods that correspond directly to the RESTful web services, e.g. onList(), onCreate(), onDelete(), onUpdate(), and onRetrieve(). The sMash runtime will automatically invoke the correct method based on the context. With the single, uber-handler, you respond to lower level events, like onPOST(), onGET(), etc., and must know how to interpret and process them. So, separate handler files containing the same script it is.
In my handler code, I grab the name of the resource from the request path. That lets me load the correct handler configuration file for the resource, i.e. the file that maps the RESTful services to the MDM services.