Darius,
I like the resources that you list in your last email, but it does not
allow searching of cohortdefinitions like Burke mentions using the
?q={query}
This I think useful instead of the more bandwidth intensive list all
cohorts and select the one you need.
We should definitely do rows-option-2, because that is how we have done it
for the other resources. i.e. in a key:value pair inside the JSON array
---
Regards,
Saptarshi PURKAYASTHA
My Tech Blog: http://sunnytalkstech.blogspot.com
You Live by CHOICE, Not by CHANCE
On 17 February 2012 11:32, Darius Jazayeri <[email protected]> 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]> 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]>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
>>
>>
>> ------------------------------
>> Click here to
>> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from
>> OpenMRS Developers' mailing list
>>
>> ------------------------------
>> 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]
