Hi! Some more thoughts regarding specific questions:
On Sat, Jan 17, 2015 at 6:20 PM, Bert Verhees <bert.verhees at rosa.nl> wrote: > > 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? > Have a look at chapter "6. Response Status Codes"starting at https://tools.ietf.org/html/rfc7231#page-47 If you want to send a deeper explanation for an error or (several errors) to users or developers the specification says: "The response message will usually contain a representation that explains the status." (For example a html-page, a txt-file or a json-document.) It is not so different from adding error explanations to standardized/reused Java exceptions when you are programming you just have even more freedom. 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. On Sat, Jan 17, 2015 at 9:37 PM, Bert Verhees <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? // 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. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150117/f41ec4c2/attachment.html>
