Keep in mind that web service URLs starting with '/ws' are not supported for 1.8.0 and earlier versions, i would like us to use this chance to probably come up with a convention for modules' REST URL pattern, this will allow to probably register common web service filters that can be shared across all modules that follow the convention.
Probably the options we have are: 1. /ws/reporting/rest/**** 2. /ws/reporting/**** 3. /ws/reportingrest/**** I prefer 1. Wyclif On Fri, Feb 17, 2012 at 10:52 AM, Darius Jazayeri <[email protected]>wrote: > 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 >> > > ------------------------------ > 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]
