|
I'm not sure that we all realise just what Microsoft are doing here. This service is not an end in itself; it's a demo of Web Services in general. Many of the suggested changes would break its compliance with Web Services standards and defeat its purpose.
Or did we mean to criticize the web services standards themselves? In that case, many of the suggested changes are moot because they are HTTP-specific. There's no point in suggesting that
web services become "more like the Web itself": they don't want to be. They are not committed to HTTP protocol, and they do not follow the REST architecture.
I will now try to evaluate the suggestions on those terms.
Putting each method at a different URL with a meaningful name: valid.
Using stronger authentication: valid.
Using HTTP digest authentication: won't work outside the Web AFAIK.
Using GET: won't work outside the Web.
URL-encoding the parameters: won't scale.
And one more thing: I don't think SOAP is trying to "sell development environments", because the message displayed in the article was feasible for a lone C programmer with a sockets library to generate and send. (Parsing the reply would require an XML parser.)
As a practical example, I just booted up the Java SDK and WSDP (total cost: zero). I fed the URL of Microsoft's WSDL to this Sun tool, and it generated a bunch of Java classes without a complaint. Adding the PIN to outgoing messages may take 12 lines of code.
David
|
Previous Message
