Thank, Isabel, You are right, you and others have put me on the right track, I know now how to proceed
best regards Bert On 19-01-15 09:07, Isabel Rom?n Mart?nez wrote: > 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 > > > > _______________________________________________ > 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/83947196/attachment.html>
