Saptarshi, I agree that we should support searching for cohort definitions via a query. Just that Burke wrote it out as using a "cohortdefinitions" resource (with an s) to query, and a "cohortdefinition" resource to fetch. And I'm disagreeing with that.
-Darius On Fri, Feb 17, 2012 at 5:21 AM, Michael Seaton <[email protected]> wrote: > ** > 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]> 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 >> > > ------------------------------ > 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]
