According to a discussion on StackOverflow, it should be allowed to use HTTP-status to communicate application response.
There is a schema http://i.stack.imgur.com/whhD1.png Here is another (maybe better) https://raw.githubusercontent.com/for-GET/http-decision-diagram/master/httpdd.png The discussion is here http://stackoverflow.com/questions/2342579/http-status-code-for-update-and-delete There are also conflicting opinions. But it seems that a big part of the world finds it OK to use HTTP-status-codes to use for application-errors as if a partyId is a resource like an HTML-document. So a client cannot distinguish between a missing service and a missing representation for an partyId. If I do this (GET) http://localhost:8080/oak/demasdaographic/435980543098 (Response generated by Restlet!) if gives the same result (404) as this (GET) http://localhost:8080/oak/demographic/435980543098 (404 should be generated by me) The first error is a not existing service and the second a not found object, but, although completely different from origin and type they have the same message. I cannot imagine that this is what people want. But it seems that they do. Instead I have this below: My question, why isn't this better? The rest community is making an error, aren't they? Message and Headers { description:"Demographic Object :435980543098 is not found." errorcode:"OBJECT_NOT_FOUND" } Status *200*OK[Show explanation] Loading time:39 Request headers User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36 Content-Type:text/plain; charset=utf-8 Accept:*/* Accept-Encoding:gzip, deflate, sdch Accept-Language:en-US,en;q=0.8,nl;q=0.6 Response headers Content-type:application/json; charset=UTF-8 Content-length:98 Server:Restlet-Framework/2.2.3 Accept-ranges:bytes Vary:Accept-Charset, Accept-Encoding, Accept-Language, Accept Date:Sat, 17 Jan 2015 22:19:42 GMT On 17-01-15 21:27, Sebastian Iancu wrote: > Hi Bert, > > I think Diego emails are right on spot and can give you some hints > about RESTful principles. > Perhaps you should consider that, what you call 'service' is actually > the 'application' itself; than details about returned codes wont be > that weird anymore. Also, URLs are resource-refs rather than actions - > so a bad URL is generally a resource-not-found or a action-not-allowed. > As far as I know, there are already few openEHR-REST-apis out there, > all behaving in a similar if not identical way in what regards > returned status codes. > > Sebastian > > On 1/17/2015 6:20 PM, Bert Verhees wrote: >> On 17-01-15 11:56, Karsten Hilbert wrote: >>> What would be the error code for when the client attempts to >>> call a non-existing service on the server ? >> >> Sorry that I come back to this once more. Karsten almost gave a good >> example, I want to explain my cause on a better but similar example. >> >> The same problem also occurs with a GET. The REST-service from >> EHRScape returns a 404 when the party is not found, while the service >> to get the party is found. >> GET /demographich/party/{partyid} >> In my opinion it should return 200, the application-service to find >> the party is found, understood the request, so there is no >> HTTP-error, but the application returns that the party is not found. >> This should be expressed in the result, not in the HTTP-status >> >> So this is a better example, suppose the client calls the wrong >> server with this URL, he probably gets a 404 because the service >> cannot be found on that server. >> >> So, if you make a REST-service giving back a 404 if the HTTP- runs >> fine, but the application cannot find something requested, you are >> giving an ambiguous message to the client, which cannot determine if >> there was a 404 on HTTP-level or a 404 on application-level. >> >> I cannot imagine that the designers from RESTlet wanted this >> ambiguity. I think this is wrong. >> >> Another reason why it is wrong to misuse the HTTP-status for >> communicating application errors is that there can be only one >> HTTP-status, and an application may want to communicate more errors. >> Where do you put those errors? In the result-data? >> >> Third reason for not using HTTP-status for application errors is that >> there is a limited number of HTTP-statusses, they have a meaning in >> the technical context of the HTTP-protocol. >> Suppose you want to communicate an error for which you cannot find a >> good HTTP-number, what do you do? >> >> So I think it is wrong to misuse the HTTP-status for communicating >> application results. >> >> Now I am leaving this subject, thanks Karsten for your support. >> >> Best regards and have a nice day. >> Bert >> >> _______________________________________________ >> 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/20150117/498c783d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: iebjjihd.png Type: image/png Size: 2079 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/498c783d/attachment-0001.png>
