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 > _________________________________________ 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]
