CRUD Restlet
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).
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
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/7a890941/attachment.html
CRUD Restlet
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
mailto:pazospablo at hotmail.com pazospablo at hotmail.com
mailto: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
mailto:openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/6b659678/attachment-0001.html
CRUD Restlet
On Sat, Jan 17, 2015 at 11:37:52AM +0100, Diego Bosc? wrote:
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.
What would be the error code for when the client attempts to
call a non-existing service on the server ?
For example: DELET /demographics/party/{partyId}
or
For example: DELETE /demographics/pardy/{partyId}
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
CRUD Restlet
Probably 405 'method not allowed' or just return a generic 400 'bad
request'. In either case you know it is your client fault.
Wikipedia is a good start for most common codes. You can see you can
cover a lot of use cases just with the codes on that page.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
2015-01-17 11:56 GMT+01:00 Karsten Hilbert Karsten.Hilbert at gmx.net:
On Sat, Jan 17, 2015 at 11:37:52AM +0100, Diego Bosc? wrote:
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.
What would be the error code for when the client attempts to
call a non-existing service on the server ?
For example: DELET /demographics/party/{partyId}
or
For example: DELETE /demographics/pardy/{partyId}
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
___
openEHR-technical mailing list
openEHR-technical at lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
CRUD Restlet
On 17-01-15 12:00, Diego Bosc? wrote: Probably 405 'method not allowed' or just return a generic 400 'bad request'. In either case you know it is your client fault. Wikipedia is a good start for most common codes. You can see you can cover a lot of use cases just with the codes on that page. http://en.wikipedia.org/wiki/List_of_HTTP_status_codes Sorry Diego, I disagree with you. There are several reasons for it. To avoid a repetition of arguments, I leave it Have a nice day. Bert
CRUD Restlet
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
CRUD Restlet
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
CRUD Restlet
://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/498c783d/attachment-0001.html -- next part -- A non-text attachment was scrubbed... Name: iebjjihd.png Type: image/png Size: 2079 bytes Desc: not available URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/498c783d/attachment-0001.png
CRUD Restlet
. There are good reasons for trying to reuse a few standardized status codes in HTTP if you can (see Fieldings dissertation etc.) but the codes are extensible if you really need to invent your own status code. That is true, but Restlet already uses 404 for a method not found, or an URL which it can not route to a method. And the community urges me to also use 404 for a completely other purpose. In this way my client application can not distinguish what happens and cannot proceed in its doing. What should report to the user? Error 404: Or the party (partyId) you are looking for does not exist in the system, or the URL to the method to find the party is wrong, or you are addressing the wrong server which does not understand the URL at all Can you imaging the customer looking. Maybe I should program the webcam when the message appears, and publish the result on the Internet. Must be big fun. Thank you (not) restlet for this On Sat, Jan 17, 2015 at 9:37 PM, Bert Verheesbert.verhees at rosa.nl mailto:bert.verhees at rosa.nl wrote: 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. Maybe it is your assumption that HTTP is a pure network layer that misleads you? Maybe the WWW is resembling a giant distributed application/ecosystem and HTTP is part of it, all layered on top of the network: TCP/IP? You are right, HTTP is not a network-layer. But I understood it to be transparent, to the application it serves. Before I was using SOAP, better error handling, because there was separation between application and protocol errors. But thanks for your comments. Time for a drink (or two) Bert // Erik P.s. Feel free to complain to Roy Fielding, IETFet.al http://et.al. about the design of HTTP and REST but for your own sake please do read relevant parts of his dissertation first. He explains the design choices very well :-) If you want to fight more fruitful REST-related battles I am sure you can find many things on the net that claim to be REST but actually do not fit the intended purpose of REST and many such designs that are actually not following the REST design patterns. :-) ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/e8cca9ba/attachment.html
