XML-RPC, SOAP, and/or REST
Dave Winer: Here's the Wiki page where people are deciding whether to use XML-RPC and/or SOAP. You can express your opinion if you like. That's how it works.
Excellent! Now lets see if we can have a respectful dialog on the subject? No hand waving or grandstanding, simple facts. I say this because this is an area ripe for flamage from all camps, not just XML-RPC and SOAP, but also REST which needs to be included in this discussion, IMHO. OK?
To start things off, Dave Winer's has expressed his opinion as XML-RPC keeps the barrier to entry super-low. There are 78 toolkits. SOAP interop is harder. Keep it simple. And if you asked me if you can use HTTPS to transport XML-RPC I would say yes. HTTPS is HTTP. Strongest reason to use XML-RPC: EVERY BLOGGING TOOL AND EDITOR TODAY SUPPORTS XML-RPC. IF IT AIN'T BROKE, DON'T FIX IT.
My current leanings matches Mark Baker's: don't want any RPC interface, be it XML-RPC or SOAP. Gimme a RESTful interface, optionally RESTful SOAP. - however, I would like to see more data before I cast my vote.
Misha Dynin has already sketched out what a SOAP binding would look like. Take an echo entry, put it in a body, add a header. Done.
I'm guessing here, but Mark Baker's example would probably look a lot more like this.
From what I have seen, most XML-RPC interfaces would not document this at the wire level at all, but would describe this in terms of structs. Anybody care to sketch out what this would look like so that we can compare apples and oranges? Just so things aren't a moving target, lets limit the scope of this to the 2003/07/01 snapshot.