Hi Bert, Sorry for my bad english. I think that any aproximation is a viewpoint of a problem and that you can solve the same problem from different viewpoints, using different paradigms. The problem is to choose the optimal and when you have no options that mix differents paradigms to find the optimal way to do this... And if you choose a paradigm you should apply it as best as possible, been conforming with it principles always that it is possible and trying not to mix with others if it is not essential, some times this only implies a little "rethinking" of the solution.
A service oriented viewpoint and a resource oriented viewpoint could solve the same problem, you only have to model your solution agree with the principles of the selected way, usually one of them is closer to your problem and would give you a better solution (more easy to implement or more clear) if you chose the correct one, sometimes it could be imposible to use only one aproximation and you have to mix them (this could produce more complex and prehaps less interoperable solutions)... In this case, if you are using a Rest viewpoint (Rest itself is resource oriented) you should be consecuent with this paradigm, so you must query for a resource. In the sample that you use "Have you ever been sick?" perhaps this is not the correct question/query it could be better if you think in "GET your episodies of sick" (where your episodies of sick could be expressed as a URL of course: .../isabel/episodies-of-sick If this resource could not exist, and this is not an "error" if it is not in the server, you could use the code response "204 No Content", for example, that means (I copy the RFC) The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent?s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent?s active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. As you could see the metainformation could be applied to the document in the user agent's active view (so it is clear that he has not been sick and this is not an error), the field "your previous sick episodies" view would remain empty for the user... Or you can consider that this resource always has to exist, so in the server the URL .../isabel/episodies-of-sick would return the resource representation <episodies-of-sick>No one</episodies-of-sick> Of course you have to manage it properly in your server side... Best Regards Isabel Rom?n El 19/01/2015 a las 6:59, Bert Verhees escribi?: > 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 > <mailto: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 > <javascript:_e(%7B%7D,'cvml','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/552b3d55/attachment.html>
