Thanks Sebastian for your reply. I have spotted some
REST-implementations which use the HTTP-status to communicate
application-circumstances.
They are mixing the network-layer (HTTP) with the application layer. It
is a very old principle and I learned to not do this. I explained why,
below.
Here on this list we mainly have to do with implementers of REST, not
REST designers. So what you see is that they all do as all do.
I want to take the question to a higher level of REST-architects, but I
know they are not very responsive. So that can take some time and pushing.
I let you know. I am not satisfied with the practice I see here.
Best regards
Bert
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
>
