I'm not much of a fan of the bloat that SOAP has acquired, but to me the point of something XML-based isn't so much the transport side but instead the API-publishing side.  The point of a WSDL or similar descriptor is to define what's available:  what methods you can call, what types of data they take, and what sorts of data they return.  Generally, you can query the server for the WSDL in addition to actually executing the calls.  To me that's the primary advantage, and the reason why a lot of clients prefer SOAP (or some other XML-RPC approach):  it's because it provides a clear, published API that you can hand off to someone and have them program against, and there are tools for basically every language that can interpret that API.  For statically-typed languages, those tools can also help make sure that your calls are at least syntactically valid, i.e. you're not making calls to methods that don't exist, or passing Strings in for integer parameters, or referencing fields off the result object that aren't there, etc.  That might not seem like a big deal, but when you're calling a totally unfamiliar API, it can help you get up to speed much faster, and when you have clients that rely on that API, it really helps everyone's peace of mind when they can be 100% sure that API isn't changing on them.<p>I'm not aware of an similar, standardized, machine-readable equivalent for REST service documentation, though I'd certainly love to know about it if there is one.