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 >