On 19/01/2015 21:01, Diego Bosc? wrote: > 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
sure - but that forces the app programmer to develop AQL queries. Now, serious programmers and system builders have to do this, but it's not unreasonable to minimise it, especially for common cases, and to help devs who may not be PhDs in openEHR, AQL, archetypes etc. So where can we help them? Well the FHIR approach is trying to hit that kind of sweet spot. The ideal version of FHIR or a FHIR-like approach, that we can work on in openEHR is to be able to generate directly from the archetype model-base FHIR profiles (and probably even some resources). - thomas > > 2015-01-19 21:58 GMT+01:00 Thomas Beale > <thomas.beale at oceaninformatics.com > <mailto: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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/74db1ff9/attachment-0001.html>
