Hi Ian, Thanks for the response. Just to clarify: as I've written, REST works for some simple cases and delivers an economic advantage as you've also expressed in the form of getting non specialist developers involved.
I for one am happy to see FHIR exploring this, which is apparently delivering good results. As I've written, we'll leave with REST, it is an industry standard now for many things. As long as we don't try to push everything into it, we should be able to see benefits. Best regards Seref On Mon, Jan 19, 2015 at 10:51 AM, Ian McNicoll <ian at freshehr.com> wrote: > Hi Seref, > > You are of course correct that FHIR or any other RESTful approaches > may struggle in more complex scenarios but I think there is increasing > evidence that simpler approaches can bring immense benefit and are an > order of magnitude easier to implement for non-specialist developers. > > In the UK, FHIR is rapidly becoming the de-facto Industry standard for > GP system interfaces butt here is strong recognition that the clinical > content development/ maintenance is not going to scale, which is why > openEHR has now been picked up (again) by the NHS. > > I think the openEHR implementer community has a huge opportunity to > show how it can play very effectively in this emerging space. > > Ian > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: ian at freshehr.com > twitter: @ianmcnicoll > > Director, freshEHR Clinical Informatics > Director, openEHR Foundation > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > On 19 January 2015 at 10:25, Seref Arikan > <serefarikan at kurumsalteknoloji.com> wrote: > > I've managed not to respond for some time but this discussion got to a > point > > where I can't help commenting :) > > > > REST is a fact of the industry, due to whatever mysterious dynamics that > > pushes various solutions down our throat as we get old in front of our > > computers. So we live with it. > > > > This does not change the fact that trying to push complex shaped objects > > through a few holes shaped as a rectangle, circle and a triangle will > leave > > some parts of those objects broken. Then we have people discussing for > ages > > what the right verb mapping would be for an operation. If you try to > express > > an infinite number of API calls and their semantics with a bunch of HTTP > > operations and status codes, this is what you get. > > > > REST may make things easy for some use cases, but do complex use cases in > > healthcare fall into that category? I should probably look at Erik's > > research at one point but my dislike for being forced to express > semantics > > with a very limited number of some text transfer protocol based concepts > > will not go away. > > > > Best regards > > Seref > > > > > > On Mon, Jan 19, 2015 at 5:59 AM, Bert Verhees <bert.verhees at rosa.nl> > wrote: > >> > >> I checked on how the large companies like Google, Amazon, PayPal, github > >> do it. > >> > >> They all have a hybrid solution. They all use an own error schema was > >> verbal terms, sometimes hierarchical, and they all map their errors to > the > >> http numerical status schema. > >> > >> This means that a query with no result is qualified as a 404 error. > >> However this seems unlogical to me, is that how the big guys it do. It > is > >> the same error which is fired when you try to call a non existing > method. > >> But the accompanying message is different. > >> > >> It is difficult for me to qualify a query which has no result as an > error. > >> Have you ever been sick? No? That is a 404 error. > >> > >> But on the other hand, that is how the big guys do it. > >> > >> Bert > >> > >> Op maandag 19 januari 2015 heeft Bert Verhees <bert.verhees at rosa.nl> > het > >> volgende geschreven: > >> > >>> Ok, you are right, but http is a very generic application layer, not to > >>> designed to serve specific application needs, but designed to serve web > >>> servers which only serve documents. > >>> As you know, a web server is a very generic application, which, from > the > >>> time Http was designed, was only recource driven. > >>> > >>> Maybe the error is that Rest uses a generic application layer which is > >>> defined as a resource driven application layer, but in fact Rest is > used as > >>> a service oriented application protocol. I think that an OpenEhr > kernel, or > >>> PayPal-service, or many other Rest using applications are also service > >>> oriented, not only resource oriented, and that therefor, a resource > oriented > >>> error handling is unable to serve the needs of a service oriented > >>> application. > >>> > >>> You could call that misusing http, because it was not designed for > that, > >>> but on the other hand, with some new thinking, Http can be used to > serve a > >>> service oriented architecture. Or do you not agree with this statement? > >>> > >>> By the way, nowhere is written that Rest must use the Http status > >>> mechanism for communicating application needs. It is written that Rest > must > >>> used http statuses for http-needs, and Restlet does do that. > >>> > >>> best regards > >>> Bert > >>> > >>> Op maandag 19 januari 2015 heeft Peter Gummer > >>> <peter.gummer at oceaninformatics.com> het volgende geschreven: > >>>> > >>>> Bert Verhees wrote: > >>>> > >>>>> The point for me is separation of transport layer and application > >>>>> layer, and each domain has its own errorhandling. > >>>> > >>>> > >>>> > >>>> Hi Bert, > >>>> > >>>> HTTP is not a transport layer protocol: > >>>> > >>>> http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol > >>>> > >>>> ?The Hypertext Transfer Protocol (HTTP) is an application protocol ?" > >>>> > >>>> Thanks for the discussion, though. I?ve learned a lot from it. > >>>> > >>>> Peter > >>> > >>> > >>> > >>> -- > >>> This e-mail message is intended exclusively for the addressee(s). > >>> Please inform us immediately if you are not the addressee. > >>> > >> > >> > >> -- > >> This e-mail message is intended exclusively for the addressee(s). > >> Please inform us immediately if you are not the addressee. > >> > >> > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at lists.openehr.org > >> > >> > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > 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/0335255e/attachment.html>
