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