Hey Darius,
I've been staring at these choices and keep going back and forth among
all 3, so I guess I don't have a strong preference. I would lean towards
whatever best fits in with standard practice and convention. Option C
seems like my preference at the moment, but I'm going to hit send before
I change my mind again. One tangential question - can we use
/ws/reporting/... rather than /ws/reportingrest/... ? Isn't "rest"
implied here? I'm happy for "reporting" to give up it's namespace to
"reportingrest" with an objective of one day bringing that functionality
into the reporting module and doing away with the reportingrest module...
Mike
On 02/16/2012 08:32 PM, Burke Mamlin wrote:
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]
<mailto:[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 <http://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
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l> from
OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[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]
