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
>
