- From: Assaf Arkin <arkin@intalio.com>
- Date: Tue, 3 Dec 2002 18:26:15 -0800
- To: "Mark Baker" <distobj@acm.org>
- Cc: <www-ws-arch@w3.org>
> DaveO recently said something similar when he suggested that a GET > binding for SOAP complicated matters by giving developers two ways to do > the same thing. So you're in good company with this belief. > > GET and POST are both application methods, and they do fundamentally > different things, as you'd expect different application methods to do. > Almost nothing that is suitable for GET is suitable for POST, and vice > versa. I definitely agree with this view, though I would not try to enforce other people to respect it. I would just comment that if an operation is implemented using GET in one situation then it should be implemented as GET in all situation and never as POST (and vice versa). Regardless, the point is that we do want to allow multiple protocol bindings for the same operation. Even if that operation is always an HTTP POST, it may also be bound to SMTP. And I may have two different ways to bind it to HTTP POST, e.g. to use different set of headers, and two ways to bind it to GET, e.g to use two different set of parameters. What I want to know, regardless of how many bindings exist, and before I even discover all of them, is how the operation would work. I want to know that form the abstract point of view (input, output, etc) it would work the same way. I guess we differ since I am looking at the definition of the operation in isolation from any specific service that offers it, and apply that view to any number of services that may offer it. I do the discovery at design time rather than run-time. arkin > > MB > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > > Will distribute objects for food >
Received on Tuesday, 3 December 2002 21:26:51 UTC