What about Option C?
GET|POST /ws/reportingrest/cohortdefinition/{uuid}
GET /ws/reportingrest/cohortdefinitions[?q={query}]
GET|POST /ws/reportingrest/datasetdefinition/{uuid}
GET /ws/reportingrest/datasetdefinitions[?q={query}]
GET /ws/reportingrest/cohort/{uuid}
GET /ws/reportingrest/dataset/{uuid}[?param=value[¶m2=value2]]
-Burke
On Thu, Feb 16, 2012 at 7:46 PM, Darius Jazayeri <[email protected]>wrote:
> Hi All, especially Mike, Burke, and Saptarshi,
>
> While working on the Pentaho sprint, we've realized that it one key way to
> help people populate data warehouses from OpenMRS without writing lots of
> brittle SQL is to write a PDI plugin for Kettle that accesses OpenMRS data
> via web services. We've always intended to have the Reporting module expose
> the ability to evaluate cohorts and datasets via web service. This will be
> broadly useful, but this sprint gives us an excuse to do it.
>
> So, we want to let Reporting expose the list of available
> CohortDefinitions, and DataSetDefinitions, and allow you to evaluate those,
> RESTfully. Ben and I discussed this today and came up with two approaches,
> so we wanted to get opinions about which way to go. Ben plans to code one
> up tomorrow morning...
>
> *Option A (Exposes more of the way the Reporting module really works. I
> prefer this, though it may be more confusing.)*
>
> *Definition Resources*
>
> GET /ws/reportingrest/cohortdefinition -> list of all cohort definitions
> GET /ws/reportingrest/cohortdefinition/UUID -> one particular cohort
> definition
>
> GET /ws/reportingrest/datasetdefinition -> list of all DSDs
> GET /ws/reportingrest/datasetdefinition/UUID -> one particular DSD
>
> Also allow definitions to be created and edited via POSTs
>
> cohortdefinition resource:
> uuid
> name
> description (in default)
> list of parameters (in default)
> href to /ws/reportingrest/evaluatedcohort/UUID // tells you how to
> evaluate this
>
> datasetdefinition is similar
>
> *Definitions are evaluated via different resources*
> *
> *
> GET /ws/reportingrest/evaluatedcohort // ERROR
> GET /ws/reportingrest/evaluatedcohort/UUID // evaluate the
> cohortdefinition with that UUID
>
> GET /ws/reportingrest/evaluateddataset // ERROR
> GET /ws/reportingrest/evaluateddataset/UUID?date=2011-01-01 // evaluate a
> DSD that has a "date" parameter against all patients
> GET /ws/reportingrest/evaluateddataset/UUID?cohort=UUID&date=2011-01-01 //
> evaluate a DSD with a parameter against a specified cohort
>
> evaluateddataset resource:
> uuid // of the underlying DSD
> metadata // column definitions, etc
> rows // either a list of lists (in the order of the columns in
> metadata) or a list of column.name -> cell value maps
>
> *Option B (Simpler, and doesn't expose the key definition/evaluated
> distinction from Reporting. Ben prefers this.)*
> *
> *
> *A single resource for each definition/evaluated pair*
> *
> *
> GET /ws/reportingrest/cohort -> list all cohort definitions (as v=ref)
> GET /ws/reportingrest/cohort/UUID -> specific definition (as v=default)
> GET /ws/reportingrest/cohort/UUID?v=evaluated -> expensive operation;
> evaluates the cohort and includes the result as a "members" property
> GET /ws/reportingrest/cohort?v=evaluated -> ERROR
>
> cohort resource
> uuid // of the cohortDefinition
> name
> description (in v=default)
> members (in v=evaluated)
> evaluationContext (in v=evaluated)
>
> GET /ws/reportingrest/dataset -> list all DSDs (as v=ref)
> GET /ws/reportingrest/dataset/UUID -> specific DSD (as v=default)
> GET /ws/reportingrest/dataset/UUID?v=evaluated -> evaluates the DSD
> GET /ws/reportingrest/dataset/UUID?v=evaluated&date=2011-01-01 -> evalutes
> DSD with a date parameter
> GET /ws/reportingrest/dataset/UUID?v=evaluated&cohort=UUID -> evaluates
> DSD against a specified cohort
>
> This doesn't lend itself to letting you create cohort definitions or DSDs
> by POSTing to WS, at least not via these resources.
>
> -Darius
> ------------------------------
> Click here to
> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
> OpenMRS Developers' mailing list
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
