RE: WSD Requirements: add a requirement about safe and idempotent characteristics

> Hey,
>
> On Tue, Dec 03, 2002 at 06:26:15PM -0800, Assaf Arkin wrote:
> > 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).
>
> Interesting.  That suggests a different model than I had in mind, or
> that I've seen presented by anybody before.  Is what you mean by that,
> that an operation such as "getStockQuote" should use the GET method all
> the time?
>
> FWIW, in my model, there is no "getStockQuote" operation, just the "GET"
> operation.  You discover it's a stock quote either after you invoke GET,
> or because you discovered the URI in a context which suggests it's a
> stock quote (like "<stockquote>http://foo.org/sunw...</stockquote>").

I am going go backtrack for a second and return to focusing on 'idempotent
characteristics' as the title suggest and to discuss parameterized request
to the service. Let's assume my paramaterized request attempts to determine
the current market value of my position in n different stocks.

The WEB offers me two ways to submit such a request: GET and POST. If my
market position is not too complex I could fit it in a single URL and submit
a GET request. This is what Dave is highlighting as a problem and I
definitely agree.

I would argue that if I use SOAP as the request mechanism, since the input
message can be of arbitrary size I would always use POST. But even if I use
HTTP bindings (without SOAP encoding) I should either always use GET or
always use POST and not mix access methods for that same operation.

This is one case where you should always use POST, in particular if you are
doing SOAP, and this is one case where the operation you are performing is
idempotent even though it happens using HTTP POST. So an 'idempotent'
attribute definitely does not mandate which HTTP operation you would do but
defines that characteristic of the WSDL operation you are doing.


> So "GET" becomes the only operation that is required for all "getFoo()"
> methods.

I believe that is how it works today. The URL you construct to make the GET
identifies the operation and that is how the HTTP protocol bindings for WSDL
1.1 work today.

arkin

>
> > 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'll hold back on providing my view of this pending the issue above.
> It's a complicated issue, but I think I have a pretty good idea for how
> to manage it.
>
> > 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.
>
> I think of it exactly the same way!
>
> MB
> --
> Mark Baker.  Ottawa, Ontario, CANADA.   http://www.markbaker.ca
>
>    Will distribute objects for food
>

Received on Wednesday, 4 December 2002 12:18:42 UTC