Hi! I agree with others here that what Bert is seeing (but perhaps not liking) is most likely proper REST behaviour.
HTTP/REST was designed to work a certain way on purpose for particular reasons that can all be found in the (very readable and well explained) dissertation of Roy Fielding, http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm As you can see in the HTTP specification (http://www.w3.org/Protocols/rfc2616/rfc2616.html) Fielding was one of its main authors of it. Traditional REST or HTTP may not fit all applications, tastes or paradigms, it was designed to be resource oriented and gracefully handle change, different clients, multi level caching, etc. It was not designed primarily for channelling application specific remote function/procedure calls (RPC) like e.g. SOAP is often used for nowadays. (SOAP is sometimes referred to as an abuse of HTTP - mostly using HTTP to get around firewalls not because HTTP was a god fit for remote procedure calls.) There are other ways to use TCP/IP than HTTP if you want an online service to look somewhat like a an API for RPC. But since the usage scenarios of the web and browsers has broadened you can also see new features being added to more recent HTTP versions (or related standards) that are not necessarily RESTful. Those that are interested issues regarding openEHR and REST are very welcome to read and comment our paper that contains many references to relevant resources and also discusses positive and negative issues with applying REST to openEHR (or similar archetype based systems) and exemplifies things where REST could to be complemented by e.g. websockets and message brokers: *Applying representational state transfer (REST) architecture to archetype-based electronic health record systems* Erik Sundvall, Mikael Nystr?m, Daniel Karlsson, Martin Eneling, Rong Chen and H?kan ?rman BMC Medical Informatics and Decision Making 2013, 13:57 doi:10.1186/1472-6947-13-57 Available free online at: http://www.biomedcentral.com/1472-6947/13/57 The background chapter gives a fairly compact introduction to REST and references to follow up. Best regards, Erik Sundvall Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 010-1036252 in Sweden) Region ?sterg?tland: erik.sundvall at regionostergotland.se (previously lio.se) http://www.regionostergotland.se/cmit/ Link?ping University: erik.sundvall at liu.se, http://www.imt.liu.se/~erisu/ On Sat, Jan 17, 2015 at 9:27 PM, Sebastian Iancu <sebastian at code24.nl> wrote: > 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 >> > > > _______________________________________________ > 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/6d829489/attachment-0001.html>
