Sad to see that go away, I liked the idea of reusing well known formats for everything. Regarding REST, I assume that nothing stops you to provide a method called "query" with the actual AQL query as a parameter :D
2015-01-19 21:58 GMT+01:00 Thomas Beale <thomas.beale at oceaninformatics.com>: > > I would agree with Isabel. > > Not everything is a resource, or should be seen as a resource. If you just > want to pull back a lump of data, that could be a 'resource', and for that > a REST service based on FHIR or some other API will make sense. > Resource-oriented stateless services are suited to some kinds of > applications, mostly readers in my view. > > A service for talking directly to an EHR data store (i.e. a CDR) could be > designed as a REST service in theory, but it's not that well matched to the > kind of service interface of pattern of calls that will be made (especially > if distributed queries and commits are to be supported). > > The interesting question is: what style of service should be used for > e-health business entities, like active care plans, managed medication > lists, and order management, which all need much more complex APIs than > just 'get'? FHIR is not designed for this kind of thing, and it's > questionable whether REST is either. The APIs in these cases need to be > carefully designed, and could easily be stateful / session-oriented - > especially if they manage a shared resource that multiple agents may try to > update simultaneously. In any case, I don't see statefulness or not as the > decider on what kind of protocol you want; structure is a bigger decider. > > I think it's easy to fall into the trap of thinking a single latest / > fashionable protocol is good for all layers of a complex architecture. > That's very unlikely to be true. I see no problem with an complete solution > having REST, SOAP, binary RPC and other kinds of interfaces. > > - thomas > > > On 19/01/2015 13:10, Isabel Rom?n Mart?nez wrote: > > Sorry, I know that this is not the list to have this discussion but the > sentence > > "I do think the REST architecture style is better than most SOAP, CORBA > and ESB solutions" > > Sounds too categorical to me!! you must study case requirements deeply and > you could not affirm this for every case!! > > States are crucial in many scenarios!! Supporting services (trading, name, > time, ...) are key in complex architectures!! Indirect communication is > essential in many healthcare scenarios!! > REST could be the best for some situations but it is not the best in any > case!! > > I'm agree with the other part > "Doing REST properly is not easy. " > As Doing any other thing in such complex use cases!! > In fact doing REST properly is too much easy that doing CORBA, for > example, properly..., the "easier" use of REST architecture style (versus > other as SOA, Distributed objects, Agents...) is one of it positive > points!! > > Best Regards > > El 19/01/2015 a las 13:10, Ralph van Etten escribi?: > > Hi, > > > On 01/19/2015 11:31 AM, Birger Haarbrandt wrote: > > The medrecord openEHR server is also based on REST and worth looking at. > There was a lot to learn from for me as the API is pretty neat. > > > > Thanks. We do our best to make the REST API of MedRecord as simple as > possible. We try to base the development of the API on actual usecases and > what kind of information in needed by (UI) clients without requiring the > users of our API to have any knowledge about openEHR or know how things > should work from a medical point of view. > > > This has lead to our current version of MedRecord (which is still work in > progress) and can be found here: > > https://mr.dev.medvision360.org/mr/apidocs/#!/ > > (see below if you want to try the API) > > > Since we want to make it easy for web application to access our APIs, we > should use whatever technique works best for web applications. Currently > this means we must use REST over HTTP, HATEOAS, JSON documents, JSON > schemas and a focus on (good) (API) documentation. > > I do think the REST architecture style is better than most SOAP, CORBA and > ESB solutions and it currently is the best way to access remote resources. > But doing REST properly is not easy. > > The current API of MedRecord consists of two pieces: > A fully automatically generated API based on the ADL files. (everything > starting with /ehr ) > And an API based on procedures (everything starting with /procedure ) > > The main difference is that the procedure API can be used without any > knowledge of openEHR. All openEHR difficulties are hidden behind the > procedure API which should make the API simple enough to be usable by any > (UI) developer not familiar with openEHR or health care. > > These two APIs are different views on the openEHR data stored in a > database. This also means we can swap the backend which we are currently > using for any other openEHR backend. > > The MedRecord API also comes with Java (and JavaScript) client libraries > which hides all the REST stuff which makes accessing resources as simple a > single line of code while providing the data as plain old Java objects. > > Also note we have two versions of MedRecord. A version based on XML and a > version not based on XML. > Our current focus lies on the version without XML and this is the version > which can be seen in the link above. > > > Since our API needs authentication, you can test our API if you go to the > following page: > > https://mr.dev.medvision360.org/mr/apidocs/#!/ > > and use the text helloletmeinplease as authToken parameter. > > For example: > > https://mr.dev.medvision360.org/mr/ehr?authToken=helloletmeinplease > > lists all EHRs currently in our development server. > > > Btw. this answer might be slightly off-topic but I wanted to explain the > process of how we developed our current API. > > > Ralph. > > MedVision360 > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > [image: Ocean Informatics] <http://www.oceaninformatics.com/> > *Thomas Beale Chief Technology Officer* > +44 7792 403 613 Specification Program, *open*EHR > <http://www.openehr.org/> > Honorary Research Fellow, UCL <http://www.chime.ucl.ac.uk/> > Chartered IT Professional Fellow, BCS <http://www.bcs.org.uk/> > Health IT blog <http://wolandscat.net/category/health-informatics/> [image: > View Thomas Beale's profile on LinkedIn] > <http://uk.linkedin.com/in/thomasbeale> > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/331ecc68/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: btn_liprofile_blue_80x15.png Type: image/png Size: 511 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/331ecc68/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 4085 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/331ecc68/attachment.jpg>
