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 > > -- 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/> View Thomas Beale's profile on LinkedIn <http://uk.linkedin.com/in/thomasbeale> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/9a3fe489/attachment-0001.html> -------------- 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/9a3fe489/attachment-0001.jpg> -------------- 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/9a3fe489/attachment-0001.png>
