I just had some extra information. A query with no result would have status 200, for example, /parties/John+Doe. When an identified resource is queried, and there is no result, than the 404 will be applicable, for example /party/123456
Op maandag 19 januari 2015 heeft Bert Verhees <bert.verhees at rosa.nl> het volgende geschreven: > 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 > <javascript:_e(%7B%7D,'cvml','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.* > > -- *This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/36813aef/attachment-0001.html>
