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

+1
 
"Plus one", but in this case not to signify agreement, but rather to correct
your definition of 'idempotent'.  Idempotence is inductively defined as
 
    f(x) = f(f(x))
 
which, by induction means that any number of applications of f has the
same result as one.  So it's 'one' and 'many', not 'zero' and 'one'.
 
You mean "safe" when you say "idempotent", and frankly, way way too many
people on these lists fall into that same trap.
 
Just My $.03
 
Walden Mathews

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, December 03, 2002 3:17 PM
To: www-ws-arch@w3.org
Subject: RE: WSD Requirements: add a requirement about safe and idempotent
characteristics


Just my $.02
 
We are using WSDL to understand how to interact with a Web service when it
is utilized as part of a business process. A service would be used in
different ways depending on whether it is idempotent or not, transactional
or not, etc. In particular, if you are interacting with a transactional Web
service that exposes an idempotent operation you would not ask that
operation to participate in a transaction or persist the fact you performed
the operation on your side, since you can retry it without any side effects.
 
There are other ways to mark an operation as idempotent, however putting
that in the WSDL abstract definition would help the tool understand how to
build the proper interaction. It would be extremely useful to see something
like that added to the WSDL abstract operation definition, regardless of
which transport protocol you use. In actual execution you might decide to
perform the operation over SMTP, TCP or a variety of other protocols.
 
If we could conclude that GET is always used for idempotent operations and
POST is always used for non-idempotent operations than we could place a
restriction on the protocol bindings such that they comply with the type of
operation described at the abstract layer, since by definition the protocol
binding follows the abstract operation definition and supports it.
 
Personally, I do not see such a clear cut division of labor between POST and
GET. And more specifically to Mark's point I do not see how DELETE is
idempotent if it removes a resource on the server. If there is a difference
between doing DELETE zero times and doing DELETE once, then by definition it
is not idempotent.
 
As a very basic example let's consider a translation service that converts
an HTML document into PDF, or an insurance quoting service that requires a
complex data structure as input in order to provide a quote for a policy.
Such a service could be implemented using HTTP POST or SMTP, but is
idempotent.
 
On the other hand, I could see a real-time stock quote retrieval service
that given a stock ticker gives you the current stock price. Since the
request is simple it could also be implemented using HTTP GET. However,
being real time means that the response should not be cached by a proxy
(which is easy to control using the cache control headers of HTTP). It also
means you get charged each time you retrieve a quote, so the service is
definitely not idempotent.
 
regards,
arkin

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Doug Bunting
Sent: Tuesday, November 26, 2002 2:20 PM
To: Mark Baker
Cc: Ugo Corda; www-ws-arch@w3.org
Subject: Re: WSD Requirements: add a requirement about safe and idempotent
characteristics


No, we're going to recognize that all POST operations are not necessarily
not idempotent.  GET is in reality used for requests that are both
idempotent and able to be sent without additional information besides HTTP
headers.  POST is in reality used for requests that are not idempotent or
require additional information or were set up against a random site
developer's (possibly misguided) whim.

That said, I'd agree knowing the HTTP method is enough to know whether the
response is cacheable using existing proxies.  I'm not entirely certain how
an idempotent attribute independent of the method helps the requester.  What
would that software due with this proposed attribute?

thanx,
    doug

Mark Baker wrote:


Hi Ugo,



On Tue, Nov 26, 2002 at 11:26:52AM -0800, Ugo Corda wrote:

  

I have the impression that Hugo wanted to also address cases where POST is
used instead of GET (because, for example, headers are to be specified), but
still the operation is idempotent. So just looking at the method would not
sufficient to tell whether the operation is idempotent or not.

    



Looking at the method will *always* be enough to know whether it's

idempotent or not.  POST is not idempotent, by definition.  PUT is

idempotent, as is GET and DELETE, also by definition.  They have

their own standalone meanings, and nothing in the body of the message

can change that.



(uh oh, are we going to have to get into the "HTTP isn't a transport

protocol" issue again? 8-)



MB