Darius,
This looks good to me. I have a strong preference for Option 2 - using
a Map from column name -> value rather than an array of values in order.
Mike
On 02/17/2012 01:02 AM, Darius Jazayeri wrote:
+1 for reporting without the rest.
I do like Option C--at least as I'm interpreting it it's basically
Option A, but with a more intuitive resource name.
So basically:
GET /ws/reporting/cohortdefinition -> list all cohort definitions
POST /ws/reporting/cohortdefinition -> create a cohort definition
(save for later)
GET /ws/reporting/cohortdefinition/{uuid} -> get one cohort definition
POST /ws/reporting/cohortdefinition/{uuid} -> edit a cohort definition
(save for later)
GET|POST /ws/reporting/cohort -> error
GET /ws/reporting/cohort/{uuid}?[param=value&cohort=uuid] -> evaluates
a cohort, supports params and base cohort
POST /ws/reporting/cohort/{uuid} -> error
So, the other question up for vote...which way of representing data
set rows should we use? (I have a weak preference for option 2.)
metadata: {
columns: [ { name: "name", label: "Pretty Name", datatype:
"java.lang.String"}, ... ]
},
rows-option-1: [
[ "Alice", 5, true ],
[ "Bob", 7, true ]
]
rows-option-2: [
{ givenName: "Alice", age: 5, hasAllVaccinations: true },
{ givenName: "Bob", age: 7, hasAllVaccinations: true }
]
-Darius
On Thu, Feb 16, 2012 at 8:06 PM, Michael Seaton <[email protected]
<mailto:[email protected]>> wrote:
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
------------------------------------------------------------------------
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]
