[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod wrote:
>>It's time to move on ... Or to put it more bluntly, "REST WON!
>>Learn to accept victory gracefully!"
>
> Let me see if I understand the sense in which REST won. The XMLP working
> group is going to add to their primer (and maybe to the SOAP spec
> itself) saying: "please don't use SOAP when HTTP GET is more
> appropriate." In other words, SOAP ceded a part of the solution space to
> HTTP.
No. They're saying that when you want to get & process a SOAP message
and the operation meets the HTTP & Web-architecture criteria (safe,
idempotent, whatever) for using GET, then you should just publish a URI
for it and use GET to get it. This seems like it fully addresses the
concerns. Concretely, next time someone like Google comes along and
says "let's make our stuff available via SOAP because that's the next
big thing", they'll read the spec, publish a URI, and deliver their
output in a SOAP wrapper. What's not to like?
There's still some work to be done in maximizing interoperability at the
URI level - is it worth the trouble to publish a standard url-encoding
scheme for Web Services services/methods/arguments? This also needs to
be worked into WSDL so that you can say "This SOAP message is GETable"
and the it'll do the right things for the Visual Basic programmer who's
frightened of angle brackets; I'm confident this will be done.
Want to know why I'm cheery about this? Because these Web Services
people aren't dumb, and we went to them and said "uh, your stuff doesn't
play well with the Web" (pointing to among other things Paul's article)
and they said "OK we'll fix it."
This is the way things are supposed to work. -Tim
|
