[
Lists Home |
Date Index |
Thread Index
]
On Wednesday 12 June 2002 7:57 pm, Paul Prescod wrote:
> Now they sit down to develop a web service with the tools they have
> available. Let's say that they have Visual Studio. So they need to
> develop a web service that uses HTTP for safe, fetching operations and
> SOAP for the rest. So they need to be familiar with both SOAP tools and
> HTTP tools. Both the "Web Services Toolkit" and .asp (or whatever). They
> need to understand both the SOAP *and* HTTP protocols. They'll need to
> deal with the fact that Microsoft wizard-izes the hell out of one but
> not the other. What will they do? Revert back to using just plain old
> SOAP for both GET and DELETE/PUT/POST.
Would it satisfy you if SOAP, in the funky wizard, let you specify (for each
method) whether it should be accessed via GET (for idempotent methods) or
POST? So that SOAP *does* expose this feature of the underlying HTTP
protocol? This information would be presented in the resulting WSDL for
clients to take note of, and should be enforced in the server by having it
reject mis-methoded requests.
And what if one defined SOAP method URLs:
soap:get:http://soap.foo.com/MyService#getName()
soap:post:http://soap.foo.com/MyService#setName("Fish")
...to bridge addressability?
I don't see 'REST vs RPC'. I see REST as just a name for certain useful
features of an RPC system... 'REST vs RPC' is like 'Cheese vs Pizza'.
The stuff about state management is far from 'un RPC' - just look at NFS.
Ugh... I sound grumpy. I don't mean it, it's just 1am here, I've been up late
fixing other people's bugs :-)
ABS
--
Alaric B. Snell
http://www.alaric-snell.com/ http://RFC.net/ http://www.warhead.org.uk/
Any sufficiently advanced technology can be emulated in software
|
