- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 21 Feb 2002 11:43:34 -0800
- To: "S. Alexander Jacobson" <alex@shop.com>
- Cc: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, Martin Gudgin <marting@develop.com>, Paul Prescod <paulp@ActiveState.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, xml-dist-app@w3.org, xml-dist-app-request@w3.org
On Thu, Feb 21, 2002 at 12:46:59PM -0500, S. Alexander Jacobson wrote: > > Another choice would be to put the responsibility for idempotency > on the client (where is resides with HTTP). If the client makes a > SOAP request using GET the server should return an error if > fulfilling the request would violate idempotency. (though this > doesn't solve the problem of being HTTP correct with respect to > status/error codes). > > Since I think people really don't want to start annotating Java > classes to generate WSDL, the second choice is better. And since, > also implicit in HTTP/REST is that the number of methods should be > very small, the natural thing to do here is to make SOAP methods > correspond directly to HTTP methods. A SOAP method HTTP-GET would > tell the HTTP binding to use GET. Perhaps the rule is that any > methods that don't correspond to HTTP methods will be transported > using POST. I don't think it's the better solution; the client is in the worst position to determine the idempotency of the request. Putting up an artificial wall that says 'WSDL must be automatically generated without additional annotation' seriously limits the ability and flexibility of Web Services. It also seems to cross a line into API design. One other thing to keep in mind here; the potential uses of a GET feature (I'm not yet convinced it's a separate binding) include but are not limited to RPC; other applications using a request-response MEP may benefit from caching as well. Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 21 February 2002 14:43:37 UTC