Proposal After Design Forum June 12, 2013

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) @raff, please check to make sure key/value pairs can be handled in both JSON and XML.   See (8) and (9) below.

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. 

(9) See the new note in the diagram about ColumnNames[].  DataRows[] can be as Darius proposes unless this causes some problem, in which case we should drop the column names and require that all rows have values for all columns.  I fear that many datasets will be sparse, resulting in many NULLs, but that may be best for JSON.  It is possible that the XML version may differ.