This resource model is proposed for this project. Additional notes:
(1) All requests use the submission mechanism. A new priority level is added for synchronous execution.
(2) The former methods to GET all cohort definitions and dataset definitions have now become appropriately typed GETs to the Definition resource.
(3) The former methods which caused evaluations of cohort definitions and dataset definitions have now become appropriately typed POSTs to the Request resource, followed by GETs once the request has been completed.
(4) All requests and associated data migrate from cache to disk to trash per the mechanism in the reporting module.
(5) Enums are passed as the English text of their values.
(6) Unlicensed user, please check to make sure key/value pairs can be handled in both JSON and XML
Second thoughts
(7) I'm thinking that rather than being subclass handlers, all 3 definitions and all 3 requests should be first-class resources. They would each contain all the current superclass fields (except Type) plus their own private fields. That way, we could at some later point incorporate their subclasses (e.g. AgeCohortDefinition, EncounterDatasetDefinition, PeriodIndicatorReportDefinition) into the model so they can be CRUDed through the REST interface.
(8) Re key-value pairs and (6) above, I am thinking that DatasetDefintions[] and Datasets[] can be represented as arrays of links, with the "rel" field being the key and the "uri" field being the uri of the resource. DataRows[] can be as Darius proposes.