Birger and Diego, Thanks for the useful pointers. I'll take these as starting points to see how healthcare IT embraces REST.
Best regards Seref On Mon, Jan 19, 2015 at 10:31 AM, Birger Haarbrandt < birger.haarbrandt at plri.de> 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. > > Best, > > Birger > > Am 19.01.2015 11:29, schrieb Diego Bosc?: > > I will just add that if you are making a server you probably want to > take a look and how FHIR does things. They have some pretty cool ideas > for common problems that you can probably reuse (e.g. using atom for > query responses) > > 2015-01-19 11:25 GMT+01:00 Seref Arikan <serefarikan at > kurumsalteknoloji.com> <serefarikan at kurumsalteknoloji.com>: > > 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> > <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> > <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> <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 listopenEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > openEHR-technical mailing listopenEHR-technical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > *Birger Haarbrandt, M.Sc.* > > Peter L. Reichertz Institut f?r Medizinische Informatik > Technische Universit?t Braunschweig und > Medizinische Hochschule Hannover > M?hlenpfordtstra?e 23 > D-38106 Braunschweig > > T +49 (0)531 391-2129 > F +49 (0)531 391-9502 > birger.haarbrandt at plri.de > http://www.plri.de > > _______________________________________________ > 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/7e854be6/attachment-0001.html>
