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>

Reply via email to