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
