[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrp] Re: Q about resource usage with http post
I have found REST to be more in touch with transaction based systems like enterprise software systems than SOAP. In many legacy systems, people are wrapping their existing stuff with SOAP yet their service calls are essentially gets, puts, posts etc. It is more natural and useful to use REST in those cases as it makes maximum use of your existing web infrastructure. This is also true, in my opinion, of WSRP. I mean at the end of the day, in WSRP we are simply doing GETs and POSTs on a remote resource that returns presentation - these are web pages people! Why then to go through the webservice route when it adds unnecessary complexity, takes much more bandwidth, requires new infrastructure, requires cluges like the initCookie protocol and doesn't really add much value to the spec per se. I understand the argument that SOAP has emerged as the de-facto standard for webservices etc. Anyway, enough of that, back to work. KM Khurram Mahmood Product Manager - Portal Solutions Off: (925) 694-9566 Cell: (408) 230-6784 "Conroy, Scott" <Scott.Conroy@constel To: Khurram_Mahmood@peoplesoft.com lation.com> cc: andre.kramer@eu.citrix.com, lars_hofhansl@peoplesoft.com, "Rich Thompson" <richt2@us.ibm.com>, wsrp@lists.oasis-open.org 11/05/2004 12:48 PM Subject: RE: [wsrp] Re: Q about resource usage with http post Well, I can't quite say that the industry at large is embracing REST, but maybe we can hope for RESTful SOAP? There's no doubt there's merit to the idea. In my case, we've been able to use our existing infrastructure (f5 application proxies, SiteMinder/TransactionMinder security tools) to good effect by developing in a RESTful way... -----Original Message----- From: Khurram_Mahmood@peoplesoft.com [mailto:Khurram_Mahmood@peoplesoft.com] Sent: Friday, November 05, 2004 2:30 PM To: Conroy, Scott Cc: andre.kramer@eu.citrix.com; lars_hofhansl@peoplesoft.com; Rich Thompson; wsrp@lists.oasis-open.org Subject: RE: [wsrp] Re: Q about resource usage with http post Scott, are you saying that finally REST architecture is winning over SOAP ;-) "Conroy, Scott" <Scott.Conroy@constel To: lars_hofhansl@peoplesoft.com, andre.kramer@eu.citrix.com lation.com> cc: "Rich Thompson" <richt2@us.ibm.com>, wsrp@lists.oasis-open.org, (bcc: Khurram Mahmood/PeopleSoft) 11/05/2004 09:04 AM Subject: RE: [wsrp] Re: Q about resource usage with http post I tend to disagree about blocking/allowing Gets/Posts. Layer 4+ devices and web servers are more frequently blocking specific HTTP verbs. Designing apps in a way that all GETs are reads, all POSTS are updates, PUTS are inserts, and DELETES are deletes is becoming an architectural best practice (though it remains uncommon so far). I have a few apps that are designed in this way. I do agree with your point about erroring out rather than converting the verb. ~Scott -----Original Message----- From: lars_hofhansl@peoplesoft.com [mailto:lars_hofhansl@peoplesoft.com] Sent: Friday, September 24, 2004 1:22 PM To: andre.kramer@eu.citrix.com Cc: 'Rich Thompson'; wsrp@lists.oasis-open.org Subject: RE: [wsrp] Re: Q about resource usage with http post Hi Andre, I think if the user-agent requests a POST and the POST for some reason cannot be tunneled through a firewall, the operation should just fail (same as it would without the presence of a consumer/portlet). I think it is an error for the consumer to instead issue a GET request (which is what we see when testing with WSRP4J). There're also security issues: A user-agent's POST that is proxied as a GET by a consumer may expose information that would have been visible otherwise, especially when using SSL. Also, personally, I would be surprised if there were potential firewall issues specifically with POST requests for two reasons: 1. A POST is not inheritly different from a GET, both are a basically a stream of bytes sent via HTTP. POSTs are encoded differently, but that is it. 2. It would not make sense, IMHO, for a firewall to filter POSTs but not GETs (assuming you have a layer 4 firewall that does protocol introspection to begin with). Both can be used to transmit information through a firewall in just the same way. A firewall may choose to block port 80 to all or some some internal hosts, but that would involve both POSTs and GETs. Thanks. -- Lars "Andre Kramer" <andre.kramer@eu. To: "'Rich Thompson'" <richt2@us.ibm.com>, wsrp@lists.oasis-open.org citrix.com> cc: (bcc: Lars Hofhansl/PeopleSoft) Subject: RE: [wsrp] Re: Q about resource usage with http post 09/24/2004 12:50 AM One reason that consumer proxying using the same HTTP verb is not mandated is that some firewall policies may not allow egress of POSTs. Resource URLs are just a best effort way to tunnel through (i.e. subvert) firewalls and we are looking to add a "getResource" operation for 2.0 so that all consumer / producer traffic can be over SOAP and I had wondered about whether input data is required for this use case. Regards, Andre From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: 23 September 2004 20:20 To: wsrp@lists.oasis-open.org Subject: Re: [wsrp] Re: Q about resource usage with http post As I read your first paragraph, I also went to using the concept of resources as the right way to accomplish what you need (i.e. the updated fragment is a resource from the Consumer's point of view). Is there a particular reason the information you want to transfer has to be via http post rather than get? This sounds a lot like some of the things I did in a previous research project, but we used http get for all the transfers. Rich lars_hofhansl@peoplesoft.com 09/23/2004 02:35 PM To wsrp@lists.oasis-open.org cc Subject [wsrp] Re: Q about resource usage with http post In our case we are implementing a mechanims for "selective page refresh" using DHTML. I.e. we have to completely bypass the Portlet Interaction model. There seems to be no specific provision for this in the WSRP Spec (V1). For example performBlockingAction() either has to return the complete markup or it has to be followed by getMarkup(), we can't just return some change information and partially update a portlet. (I realize that when multiple portlets are displayed by a Consumer and one of the portlets needs to be re-rendered that the Consumer may re-render all portlet, which breaks our selective refresh paradigm for that case.) For these reasons we're trying to POST to resourceURL in order to handle our data exchange, then update the representation using DHTML based on the exchanged information without triggering any (Consumer visible) refreshes in the Consumer. Now, the V1 WSRP spec in 10.2.1.1.3.1 says that the cosumer is "encouraged to use the same communication style (e.g. HTTP Get or POST)" that was used by the user-agent. That does not seem to mandate that behavior and thus we cannot assume that all Consumers will indeed behave that way. Thanks. -- Lars Rich Thompson wrote: I don't know of cases where people have used http post in this manner, but the spec anticipates that such cases may exist and allows the markup to specify use of post with the requirement that the Consumer then also use post when passing the request on to the resource url. This keeps the Consumer truly acting as a proxy for these resources. Rich ricky_frost@peoplesoft.com 09/21/2004 05:36 PM To wsrp@lists.oasis-open.org cc Subject [wsrp] Q about resource usage with http post Is HTTP post supported for resource operations according to the spec? My reading of it points to an ambiguous statement to that effect on pg 62, section 10.2.1.1.3.1 Thanks To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgrou p.php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgrou p.php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgrou p.php. >>> The information contained in this e-mail transmission is privileged and/or confidential intended solely for the exclusive use of the individual addressee. If you are not the intended addressee you are hereby notified that any retention, disclosure or other use is strictly prohibited. If you have received this notification in error, please immediately contact the sender and delete the material. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgrou p.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]