There are specific errors to wrong method calls, unsupported mime, etc.
As long as the server returns the correct code then there won't be
interpretation errors.
The thing is that as long as a code is returned, you know that the
server is up and has given you a response based on your request. By
the code you can tell you more things.
2xx messages tell you that the request was a success
4xx messages tell you that there was a client error
5xx messages tell you that there was a server error
On your example 404 is correct because your client requested to delete
an non existing resource, which is a client error.
2015-01-17 10:56 GMT+01:00 Bert Verhees <bert.verhees at rosa.nl>:
> On 17-01-15 10:24, Diego Bosc? wrote:
>
> I agree, 404 seems the right code for this. Http talks about "resources":
> when an internet browser returns a 404 is because the specified resource you
> are asking for couldn't be found on the server, which is exactly the same
> use case Bert said (the resource you are trying to delete was not find on
> the server).
>
>
> I think the resource which is meant is the method to delete a party. For
> example if the url to the method is wrong, it should return a 404.
>
> Imagine you are writing a client and you check for the 404 or success to
> return, how easy can you misinterpret the return if you, f.e., are
> addressing the wrong server.
>
> I think, using HTTP-errors for application-errors, how tempting this may be
> in some situations, is steaming towards hard to find bugs.
>
> So a client first wants to check if the HTTP-call succeeded, and then it
> wants to know how the application responses to the action.
> It does not want a return value which can be ambiguously saying something
> about the HTTP-mechanism or the application, what ever is first.
>
> If this is the normal behaviour in REST, I think it is a failure, which we
> should not take over.
>
> Bert
>
> El 17/1/2015 2:19, "pazospablo at hotmail.com" <pazospablo at hotmail.com>
> escribi?:
>>
>> Hi Bert, that's a REST Web Services convention. REST reuses a lot of the
>> HTTP infrastructure, like methods, status codes, sone headers, etc.
>>
>>
>> Sent from my LG Mobile
>>
>> ------ Original message------
>>
>> From: Bert Verhees
>>
>> Date: Fri, Jan 16, 2015 8:18 PM
>>
>> To: For openEHR technical discussions;
>>
>> Subject:CRUD Restlet
>>
>> I was looking at EHRScape, I should have posted this question there, but
>> the Community-page does not show any communication-means, only adds.
>>
>> And maybe the question is also generic and are more people thinking about
>> this.
>>
>> I am wondering about the HTTP-errors, they seem to be used for
>> communicating application-errors.
>> I think this could be an error.
>>
>> For example, if you look at the: DELETE /demographics/party/{partyId}
>>
>> It can return a 404 with explanation: 404 Not found - the specified party
>> was not found (DEMO-6021).
>>
>> I think this is possible wrong, because on HTTP-level the call was an
>> success, and should therefor return 200, meaning, the request is received
>> and understood, and processed.
>> In the return-message it should IMHO, if necessary the result and
>> error-message on application level.
>>
>> Someone thoughts about this?
>>
>> Thanks
>> Bert
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
