CRUD Restlet
Bert Verhees wrote: The point for me is separation of transport layer and application layer, and each domain has its own errorhandling. Hi Bert, HTTP is not a transport layer protocol: http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol ?The Hypertext Transfer Protocol (HTTP) is an application protocol<http://en.wikipedia.org/wiki/Application_protocol> ?" Thanks for the discussion, though. I?ve learned a lot from it. Peter -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/d409ec94/attachment.html>
CRUD Restlet
r example, if we >take option 1 above, and request and invalid book ID, we get back a 404 >Error Code. From the developer perspective, have we actually typed in the >wrong host name, or an invalid book ID? It's not immediately clear. In >Option 3 (DAS), we get back a blank page with no information. To view the >actual error code, you need to run a network sniffer, or point your browser >through a proxy. For all these reasons, I think Option 4 has a lot to >offer. It significantly lowers the barrier for new developers, and enables >all information related to a web service to be directly viewable within a >web browser. >- *Application Specific Errors:* Option 1 has the disadvantage of not >being directly viewable within a browser. It also has the additional >disadvantage of mapping all HTTP error codes to application specific error >codes. HTTP status codes are specific to document retrieval and posting, >and these may not map directly to your application domain. For example, one >of the DAS error codes relates to invalid genomic coordinates (sequence >coordinate is out of bounds/invalid). What HTTP error code would we map to >in this case? >- *Machine Readable Error Codes:* As a third criteria, error codes >should be easily readable by other applications. For example, the XooMLe >application returns back only human readable error messages, e.g. "Invalid >Google API key supplied". An application parsing a XooMLe response would >have to search for this specific error message, and this can be notoriously >brittle -- for example, the XooMLe server might simply change the message >to "Invalid Key Supplied". Error codes, such as those provided by DAS are >important for programmatic control, and easy creation of exceptions. For >example, if XooMLe returned a 1001 error code, a client application could >do a quick lookup and immediately throw an *InvalidKeyException.* > > Based on these three criteria, here's my vote for best error handling > option: > > > >- Use HTTP Status Codes for problems specifically related to HTTP, and >not specifically related to your web service. > - When an error occurs, always return an XML document detailing the >error. > - Make sure the XML error document contains both an error code, and a >human readable error message. For example: > > >1001 >Invalid Google API key supplied > > > By following these three simple practices, you can make it significantly > easier for others to interface with your service, and react when things go > wrong. New developers can easily see valid and invalid requests via a > simple web browser, and programs can easily (and more robustly) extract > error codes and act appropriately. > The Amazon.com web services API follows the approach of returned XML > document can specify an *ErrorMsg* element. > XooMLe also follows this approach. (XooMLe provides a RESTful API wrapper > to the existing SOAP based Google API). > Another approach is by DAS ( Distributed Annotation System) which always > returns 200 if there was no HTTP-error and has error information in the > HTTP-header, which is less favorable, because it is not human readable, as > a browser does not display the HTTP-header. > > --- > End Quoting > > Best regards > Bert > > > -- *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/17134ad5/attachment-0001.html>
CRUD Restlet
ms can easily > (and more robustly) extract error codes and act appropriately. > > The Amazon.com <http://Amazon.com> web services API follows the > approach of returned XML document can specify an /ErrorMsg/ element. > XooMLe also follows this approach. (XooMLe provides a RESTful API > wrapper to the existing SOAP based Google API). > Another approach is by DAS ( Distributed Annotation System) which > always returns 200 if there was no HTTP-error and has error > information in the HTTP-header, which is less favorable, because it is > not human readable, as a browser does not display the HTTP-header. > > --- > End Quoting > > Best regards > Bert > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/f6b08cbe/attachment-0001.html>
CRUD Restlet
as a browser does not display theHTTP-header. --- End Quoting Best regards Bert -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/8d788913/attachment.html>
CRUD Restlet
NP, but it is not a matter of opinion when there are conventions, principles and guidelines. Of course it is your decision to not follow. BTW, I've found that the Facebook API returns 200 even if there are app level errors. So I think this is a by-API decision. If you want to implement a client for an API, you should follow the rules defined by that API. Cheers,Pablo. -- Original message--From: Bert VerheesDate: Sun, Jan 18, 2015 6:22 AMTo: pazospablo at hotmail.com;Cc: openehr-technical at lists.openehr.org;Subject:Re: CRUD Restletthanks,?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 regardsBert. Op zondag 18 januari 2015 heeft 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 :) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/285d266a/attachment.html>
CRUD Restlet
f XooMLe returned a 1001 error code, a client application could do a quick lookup and immediately throw an InvalidKeyException. Based on these three criteria, here's my vote for best error handling option: Use HTTP Status Codes for problems specifically related to HTTP, and not specifically related to your web service. When an error occurs, always return an XML document detailing the error. Make sure the XML error document contains both an error code, and a human readable error message. For example: 1001 Invalid Google API key supplied By following these three simple practices, you can make it significantly easier for others to interface with your service, and react when things go wrong. New developers can easily see valid and invalid requests via a simple web browser, and programs can easily (and more robustly) extract error codes and act appropriately. The Amazon.com web services API follows the approach of returned XML document can specify an ErrorMsg element. XooMLe also follows this approach. (XooMLe provides a RESTful API wrapper to the existing SOAP based Google API). Another approach is by DAS ( Distributed Annotation System) which always returns 200 if there was no HTTP-error and has error information in the HTTP-header, which is less favorable, because it is not human readable, as a browser does not display the HTTP-header. --- End Quoting Best regards Bert -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/7cce045d/attachment.html>
CRUD Restlet
For information: See therecommendations by Ethan Cerami: Specialties: Cancer genomics, bioinformatics, scientific computing, software engineering, project management. https://www.linkedin.com/in/ecerami http://www.oreilly.com/pub/au/806 Read: http://archive.oreilly.com/pub/post/restful_error_handling.html#__federated=1 Quoting: Conclusion: * *Human Readable Error Messages:* Part of the major appeal of REST based web services is that you can open any browser, type in the right URL, and see an immediate response -- no special tools needed. However, HTTP error codes do not always provide enough information. For example, if we take option 1 above, and request and invalid book ID, we get back a 404 Error Code. From the developer perspective, have we actually typed in the wrong host name, or an invalid book ID? It's not immediately clear. In Option 3 (DAS), we get back a blank page with no information. To view the actual error code, you need to run a network sniffer, or point your browser through a proxy. For all these reasons, I think Option 4 has a lot to offer. It significantly lowers the barrier for new developers, and enables all information related to a web service to be directly viewable within a web browser. * *Application Specific Errors:* Option 1 has the disadvantage of not being directly viewable within a browser. It also has the additional disadvantage of mapping all HTTP error codes to application specific error codes. HTTP status codes are specific to document retrieval and posting, and these may not map directly to your application domain. For example, one of the DAS error codes relates to invalid genomic coordinates (sequence coordinate is out of bounds/invalid). What HTTP error code would we map to in this case? * *Machine Readable Error Codes:* As a third criteria, error codes should be easily readable by other applications. For example, the XooMLe application returns back only human readable error messages, e.g. "Invalid Google API key supplied". An application parsing a XooMLe response would have to search for this specific error message, and this can be notoriously brittle -- for example, the XooMLe server might simply change the message to "Invalid Key Supplied". Error codes, such as those provided by DAS are important for programmatic control, and easy creation of exceptions. For example, if XooMLe returned a 1001 error code, a client application could do a quick lookup and immediately throw an /InvalidKeyException./ Based on these three criteria, here's my vote for best error handling option: * Use HTTP Status Codes for problems specifically related to HTTP, and not specifically related to your web service. * When an error occurs, always return an XML document detailing the error. * Make sure the XML error document contains both an error code, and a human readable error message. For example: 1001 Invalid Google API key supplied By following these three simple practices, you can make it significantly easier for others to interface with your service, and react when things go wrong. New developers can easily see valid and invalid requests via a simple web browser, and programs can easily (and more robustly) extract error codes and act appropriately. The Amazon.com web services API follows the approach of returned XML document can specify an /ErrorMsg/ element. XooMLe also follows this approach. (XooMLe provides a RESTful API wrapper to the existing SOAP based Google API). Another approach is by DAS ( Distributed Annotation System) which always returns 200 if there was no HTTP-error and has error information in the HTTP-header, which is less favorable, because it is not human readable, as a browser does not display the HTTP-header. --- End Quoting Best regards Bert -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150118/c46a8d6f/attachment.html>
CRUD Restlet
On 18-01-15 11:49, Erik Sundvall wrote: > Why do you see the status 404 as an evil error status but 200 as some > totally other kind of status? Restlet has implemented 404 as an evil error: it means: if it cannot route your URL, it returns 404. So a client application has no useful information from that 404. The client application has to take further steps to interpret the 404 status. This is inefficient. Bert
CRUD Restlet
On 18-01-15 11:32, Diego Bosc? wrote: > > You are not asking for a person, you are asking the server for a > specific document about a patient that does not exist. A server can > have records with identifiers 111, 112, 113, etc. which can be about > the same patient or not. If you ask the server for a inexistent > document identifier it gives you 404. Document identifier doesn't mean > patient identifier. > I agree, using the HTTP-status is a tempting idea, because, it looks like we are requesting a document. But we aren't. REST is not for a normal document-service. For that a normal webserver is sufficient. REST is for giving a web-interface to an application, and I ask that application to create a document about a partyId, and that application creates the document with information: "This person is not in our system" That is not an error, the application gets a command to supply information about a person in context of that application, and the application does so. I think that is good. It sometimes happens that people are thinking in isolation. I know this can happen to me. I am then making a point of something no-one seems to make a point of. But regardless that risk, I have posted this question to several forums because I think this is important, and maybe I find support for my way of thinking. Bert > El 18/1/2015 11:21, "Bert Verhees" <mailto:bert.verhees at rosa.nl>> escribi?: > > > https://developers.google.com/drive/web/handle-errors > > > This is exactly my point, 404 is for handling errors, someone not > being in a hospital-register is not an error. To check if someone > is, and he isn't, that is not necessarily an error. > It may even be a good thing, that someone never has been ill in a > specific hospital. > The only thing that a computer, without value judgment can say, is > that the call iss successful (HTTP-status 200), and the answer is > "No, he is not in the register". That is information. > > To call an non-existing service, that is an error, and should > return 404. That is what Restlet also has implemented. > > Bert > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > <mailto: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/20150118/27033f94/attachment.html>
CRUD Restlet
Hi Bert! Are you sure you have understood the difference between service orientation and resource orientation? The background chapter in our paper I referred to earlier briefly touches upon what a resource is, Fielding's dissertation explains it in detail. Why do you see the status 404 as an evil error status but 200 as some totally other kind of status? Both are normal status codes telling different things. If you consider 404 being an error or just a plain "there is no such resource/patient-id"-message depends on context and your perspective and what you expected to find at that uri. If you are sending an invalid call to the resource/service you'll most likely get another status code than 404. 404 often indicates that you sent a proper valid request to a fully functional server server but asked for something that is not there. http://example.org/registry-x/id/123456 is a pointer to a specific resource, either it exists or not. 404 says it does not. In the implementation you describe it seems like patient IDs are modelled as resources. Most (good) REST designs will let you get information about usage and status/availability of the containing resource (probably a or registry id-query resource/"service" in your case) by chopping of the last piece of the URL, for example http://example.org/registry-x/ or http://example.org/registry-x/id/ if that is what you want to know the status/availability of. 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 Sun, Jan 18, 2015 at 11:21 AM, Bert Verhees wrote: > > https://developers.google.com/drive/web/handle-errors >> >> > This is exactly my point, 404 is for handling errors, someone not being in > a hospital-register is not an error. To check if someone is, and he isn't, > that is not necessarily an error. > It may even be a good thing, that someone never has been ill in a specific > hospital. > The only thing that a computer, without value judgment can say, is that > the call iss successful (HTTP-status 200), and the answer is "No, he is not > in the register". That is information. > > To call an non-existing service, that is an error, and should return 404. > That is what Restlet also has implemented. > > Bert > > > ___ > 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/20150118/ef185396/attachment-0001.html>
CRUD Restlet
You are not asking for a person, you are asking the server for a specific document about a patient that does not exist. A server can have records with identifiers 111, 112, 113, etc. which can be about the same patient or not. If you ask the server for a inexistent document identifier it gives you 404. Document identifier doesn't mean patient identifier. El 18/1/2015 11:21, "Bert Verhees" escribi?: > > https://developers.google.com/drive/web/handle-errors >> >> > This is exactly my point, 404 is for handling errors, someone not being in > a hospital-register is not an error. To check if someone is, and he isn't, > that is not necessarily an error. > It may even be a good thing, that someone never has been ill in a specific > hospital. > The only thing that a computer, without value judgment can say, is that > the call iss successful (HTTP-status 200), and the answer is "No, he is not > in the register". That is information. > > To call an non-existing service, that is an error, and should return 404. > That is what Restlet also has implemented. > > Bert > > ___ > 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/20150118/ec63e9fb/attachment.html>
CRUD Restlet
> https://developers.google.com/drive/web/handle-errors > This is exactly my point, 404 is for handling errors, someone not being in a hospital-register is not an error. To check if someone is, and he isn't, that is not necessarily an error. It may even be a good thing, that someone never has been ill in a specific hospital. The only thing that a computer, without value judgment can say, is that the call iss successful (HTTP-status 200), and the answer is "No, he is not in the register". That is information. To call an non-existing service, that is an error, and should return 404. That is what Restlet also has implemented. Bert
CRUD Restlet
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 > ; > > *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 > 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 > 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>
CRUD Restlet
I think you are comparing a not-so-good rest web service with a perfect soap one. I.e. returning a 404 is wrong for 'method not found' (I have put already the correct code in this same thread). Lack of standard codes makes soap WS much more difficult IMHO. El 17/1/2015 23:35, "Bert Verhees" escribi?: > . > > > 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 > 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.orghttp://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/20150118/72653a72/attachment.html>
CRUD Restlet
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 VerheesDate: Sat, Jan 17, 2015 8:35 PMTo: 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 youreally 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 happensand cannot proceed in its doing. What should report to the user? "Error 404:? Or the party (partyId) you are looking for does notexist 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 understandthe URL at all" Can you imaging the customer looking. Maybe I should program thewebcam when the message appears, and publish the result on theInternet. Must be big fun. Thank you (not) restlet for this On Sat, Jan 17, 2015 at 9:37 PM, Bert Verhees??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.orghttp://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/20150118/c29d1ffe/attachment-0001.html>
