We need another WS- spec, WS-Get. It's the Get subset of WS-Transfer that just has Get. In the same way that HTTP Put/Delete are used less than Get, so I think that WS-Transfer verbs other than Get will be used less than Get.
WS-MetadataExchange is a perfect example of a spec that could use WS-Get. WS-Mex can't really refer to WS-Transfer because there's too many extra verbs. With WS-Get, WS-MEX could define GetMetadata and refer to WS-Get, and WS-Transfer could define Create/Update/Delete and refer to WS-Get. Cool.
We can still get to is a place where applications can choose:
- generic reads, generic writes: WS-Get + refactored WS-Transfer
- generic reads, specific writes: WS-Get + application specific verbs
- specific reads, specific writes: applicaiton specific verbs
I've argued the middle choice is a sweet spot that we should enable, ie Web services needs transfer protocols and specific protocols.
There's one additional piece that I would put into WS-Get, which is an optional binding to HTTP Get. As Chris said, SOAP 1.2 should have done a binding between SOAP infoset and HTTP GET + URIs. I'd proposed a SOAP RPC URI binding a long time ago. This and other proposals were rejected in favour of the soap-response MEP, which I think was a terrible solution. But the story isn't over, as WS-Get + binding to HTTP GET can give the advantages of SOAP + re-use of HTTP. I think there's more that WSDL 2.0 should do, but that's a separate issue.
WS-Get can enable HTTP GET for Web services read operations (including GET) and HTTP POST for all other Web service operations. Then the SOAP folks get what they want (the soap and wsdl extensibility models) and the REST folks get what they want (the use of URIs and use of HTTP GET).
