I've relocated this blog to my own server. More control, RSS. Mmmm...

Sam responds;

For those who want to understand the issue Mark has with SOAP, he objects to the string "doGoogleSearch" in this example. FWIW, I don't see how this is any different, architecturally, than hidden controls in HTML.

It isn't any different than hidden controls, but I wouldn't use hidden controls either. I'd just POST the data "q=foo" to whatever URI the POST form told me too. No need to understand what "doGoogleSearch" means, because the context in which the POST operation is to be interpreted by the server, is provided entirely by the URI to which I'm POSTing.

Sam asks;

Now it turns out that the Google API has a limit of a 1,000 queries per day. This means that the 1,001st query will not have the same result as the 1,000th query. The query itself has a (GASP!) side effect. It is most decidedly not idempotent. So what do you do? Call back the Hobbits and recode to use POST, or do you make the pragmatic decision to slightly bend the rules a bit?

Well, first of all, that part of 2116 that you referred to earlier in your blog (presumably you meant 9.1.1 not 9.1.2) says "SHOULD NOT", not "MUST NOT". The reason this is so, is because unsafe GETs won't break the Web; web page counters demonstrated that. What will break the Web is if people who click on a URI get blamed for causing the side-effect, as 9.1.1 points out when it says "The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.". Also, it's not a fundamental axiom, in the same way that a uniform interface is - it's derivate (though lots of other important principles are too).

But with that said, your example is an excellent one, because clearly a counter such as the one you describe would be "blaming" the user for bumping it up by one. So IMO, no, this service should not use GET, at least for those queries. It should be bootstrapped with GET though, so that you GET the HTML form, but the form results should be POSTed back.

Also, in case you were going to suggest that this somehow makes the Google API "ok" because it uses POST, it should be noted that it doesn't use POST, it tunnels through it. A client needs to know more than just the URI, the form structure, and the POST method. It needs to know what the string "doGoogleSearch" means.

And as for RSS, I welcome any suggestions for a blogging tool/service that provides free RSS feeds and lets me edit from a browser (something that Dave Winer seems dead set against providing - or at least he was in the past).

Sometimes I see signs of smart folks figuring out how to do Web services properly, and I feel a glimmer of hope that the industry may not be wasting hundreds of millions of dollars with SOAP and WSDL. Then I see stuff like this, and I realize, nope, it's going to hell - specifically this part;

Bergandi: With a wizard-based environment within the SOAPswitch. The SOAPswitch itself has self-discovery capabilities. It has the ability to, in the example I gave you, inquire into the metadata of what the Siebel system looks like; discover what business objects are available and what methods are available against those business objects; and then, based upon that, in a very, very simple way, generate all the SOAP that's required for communication.

Internet-scale distributed computing just ain't that easy, folks, sorry.