The created version was very close to C. Cohorts and datasets are not persisted aver evaluation in the reporting module. So each subsequent call is a new query to the db.
Yes, it can handle any number of parameters, spring just passing all the httprequest object. The result is a json object. If BIRT or Jasper can read that, then we're golden. Kettle/Spoon in Pentaho doesn't read it natively, so Darius is creating the plugin to know what to do with the results. Ben On Wed, Feb 22, 2012 at 12:42 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > +1 for C with modifications**** > > ** ** > > Can Spring handle an arbitrary set of parameters?**** > > ** ** > > Aren't cohorts/datasets persistent? Part of the session context? Does it > make sense not to evaluate an already evaluated cohort/dataset on GET? > That is**** > > GET /ws/reporting/cohort?cohortdef=uuid¶m1=value1[¶m2=value2…] -> > evaluates a cohort def (error if cohortdef not provided or uuid does not > represent a cohort definition)**** > > GET /ws/reporting/cohort/uuid -> returns an already-evaluated cohort > (error if uuid does not represent a cohort)**** > > DELETE /ws/reporting/cohort/uuid -> deletes an already-evaluated cohort > (no error if uuid is not a cohort)**** > > similar for dataset**** > > ** ** > > Also we should make sure that the transformation of whatever we return > into something usable by BIRT or Jasper reports is easy as pie**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Burke > Mamlin > *Sent:* Friday, February 17, 2012 11:35 AM > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] Reporting Web Service**** > > ** ** > > Given that we'd like to converge toward a convention of exposing RESTful > web services, I prefer #2:**** > > ** ** > > /ws/reporting/******** > > ** ** > > If we want to support different protocols (e.g., SOAP or some new protocol > that comes along in the future), I'd rather namespace those somewhere other > than /ws/**** and remove unneeded redundancy from our URLs.**** > > ** ** > > -Burke**** > > On Fri, Feb 17, 2012 at 11:01 AM, Wyclif Luyima <[email protected]> > wrote:**** > > 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 > **** > > ** ** > ------------------------------ > > 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]
