thanks, Pablo. Since Rest is not a standard, it is a matter of agreeing or not. I'm not sure how to proceed. It is not that having it one way or the other is a lot of work to implement. It is just, what seems better. I was often stubborn, Rowing against the general opinion was often to my advantage. I will think it over.
I wish to thank you all for the discussion and the info. Best regards Bert. Op zondag 18 januari 2015 heeft pazospablo at hotmail.com < pazospablo at hotmail.com> het volgende geschreven: > Hi Bert, this is not really a matter of agreeing or not, or if it's good > or bad reusing http status codes: is the way REST services work. If you > don't like it, you should use SOAP. > > > Every REST API out there uses status codes for app info, twitter, google, > .... > > > https://dev.twitter.com/overview/api/response-codes > > > https://developers.google.com/drive/web/handle-errors > > > This is a really nice guide I use a lot, it helped me to understand the > "REST way" of doing things > http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api > > > Bottom line, it is no good or bad, it is the REST way :) > > > > Pablo. > > > Sent from my LG Mobile > > ------ Original message------ > > *From: *Bert Verhees > > *Date: *Sat, Jan 17, 2015 8:35 PM > > *To: *openehr-technical at lists.openehr.org > <javascript:_e(%7B%7D,'cvml','openehr-technical at lists.openehr.org');>; > > *Subject:*Re: 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 Verhees <bert.verhees at rosa.nl > <javascript:_e(%7B%7D,'cvml','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, IETF 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 > listopenEHR-technical at lists.openehr.org > <javascript:_e(%7B%7D,'cvml','openEHR-technical at > lists.openehr.org');>http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > -- *This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.* -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/794b8a04/attachment.html>
