关于其余部分：基于文档或RPC的Web服务

Document or RPC based web services

我的直觉是在实践中首选基于文档的Web服务-这是其他人的经验吗？他们更容易支持吗？ (我注意到SharePoint在其WSDL界面中将Any用作"文档类型"，我想这使它成为基于Document的)。

另外-人们现在是否为相同的功能同时提供WSDL和Rest类型的服务？ WSDL在代码生成方面很流行，但对于PHP和Rails等前端，他们似乎更喜欢休息。

如果您使用的是需要服务描述(WSDL)的SOAP Web服务，那么文档与RPC只是一个问题。 RESTful Web服务不使用WSDL，因为它无法描述WSDL，并且感觉REST更简单易懂。有人提出WADL作为描述REST服务的一种方式。

诸如Python，Ruby和PHP之类的语言使使用REST更容易。 WSDL用于生成可以从静态语言轻松调用的C＃代码(Web服务代理)。当您在Visual Studio中添加服务引用或Web引用时，会发生这种情况。

是否提供SOAP或REST服务取决于用户数量。服务是通过Internet使用还是仅在组织内部使用都会影响您的选择。 SOAP可能具有一些功能(WS- *标准)，可以很好地用于B2B或内部使用，但对于Internet服务却很不利。

在此IBM DevelopWorks文章中描述了针对SOAP服务的文档/文字与RPC的比较。就互操作性(Java到.NET等)而言，文档/文字通常被认为是最佳使用方式。至于是否更容易支持，则取决于您的情况。我个人的观点是，人们倾向于使这些东西变得比所需的更加复杂，而REST的更简单方法是优越的。

如前所述，最好尽可能选择基于RPC编码的Document Literal。
确实，旧的Java库(Axis1，Glue和其他史前的东西)仅支持RPC编码，但是在当今最现代的Java SOAP库中，它不支持(例如AXIS2，XFire，CXF)。
因此，仅当您知道需要与性能不佳的使用者打交道时，才尝试公开RPC编码的服务。但是话又说回来，也许XML RPC可以帮助这些传统实现。

BiranLy的答案很好。我只想补充一下document-vs-RPC也可以归结为实现问题。我们发现Microsoft优先使用Document，而基于Java的库则基于RPC。无论您选择什么，都要确保您知道其他潜在客户也将承担什么。