.
>
> 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
> <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>
