我的直觉是基于文档的 Web 服务在实践中是首选 - 这是其他人的经验吗？他们更容易得到支持吗？ （我注意到 SharePoint 在其 WSDL 接口中使用 Any 作为“文档类型”，我猜这使得它基于文档）。
另外 - 人们现在是否为相同的功能同时提供 WSDL 和 Rest 类型服务？ WSDL 在代码生成方面很流行，但对于 PHP 和 Rails 等前端，他们似乎更喜欢休息。
WSDL) 的 SOAP Web 服务，文档与 RPC 只是一个问题。 RESTful Web 服务并不是不使用 WSDL，因为服务无法用它来描述，感觉 REST 更简单、更容易理解。有些人提出使用 WADL 作为描述 REST 服务的方式。
Python、Ruby 和 PHP 等语言使使用 REST 变得更加容易。 WSDL 用于生成可以从静态语言轻松调用的 C# 代码（Web 服务代理）。当您在 Visual Studio 中添加服务引用或Web引用时，会发生这种情况。
您提供 SOAP 还是 REST 服务取决于您的用户群体。这些服务是通过互联网使用还是仅在组织内部使用会影响您的选择。 SOAP 可能具有一些非常适合 B2B 或内部使用的功能（WS-* 标准），但不适合 Internet 服务。
这篇 IBM Developer 文章 描述了 SOAP 服务的文档/文字与 RPC。就互操作性（Java 到 .NET 等）而言，文档/文字通常被认为是最好的使用方式。至于是否更容易支持，那就要看你的情况了。我个人的观点是，人们倾向于让事情变得比实际需要的更复杂，而 REST 更简单的方法更优越。
如前所述，尽可能选择文档文字而不是 RPC 编码更好。 确实，旧的 Java 库（Axis1、Glue 和其他史前的东西）仅支持 RPC 编码，但是当今最现代的 Java SOAP 库却不支持它（例如 AXIS2、XFire、CXF）。 因此，仅当您知道需要与无法做得更好的消费者打交道时，才尝试公开 RPC 编码的服务。但话又说回来，也许 XML RPC 就可以帮助这些遗留实现。
BiranLy 的回答非常好。我想补充一点，文档与 RPC 也可以归结为实现问题。我们发现 Microsoft 更喜欢文档，而我们基于 Java 的库则基于 RPC。无论您选择什么，请确保您知道其他潜在客户也会假设什么。