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>: >> 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 -- *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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/cde7bf6d/attachment.html>
