+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]<mailto:[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]<mailto:djazayeri%[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]<mailto:[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]<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 ________________________________ 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
