基于文档或RPC的Web服务

Question

我的直觉是基于文档的Web服务在实践中是首选 - 这是其他人的体验吗？ 它们更容易支持吗？ （我注意到SharePoint在其WSDL接口中使用Any作为“文档类型”，我猜这使得它基于Document）。

此外 - 人们现在是否提供相同功能的WSDL和Rest类型服务？ WSDL很受代码生成的欢迎，但对于像PHP和Rails这样的前端，他们似乎更喜欢休息。

Answer 1

如果您使用需要服务描述（ 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- *标准），但对于互联网服务却很糟糕。

此IBM DevelopWorks文章中描述了Document / literal与RPC for SOAP服务。 文档/文字通常被认为是最好的互操作性（Java到.NET等）。 至于是否更容易支持，这取决于您的具体情况。 我个人的观点是，人们倾向于使这些东西比它需要的更复杂，而REST的简单方法更优越。

Answer 2

如前所述，最好尽可能选择Document Literal over RPC编码。 确实，旧的Java库（Axis1，Glue和其他史前的东西）只支持RPC编码，但是在当今最现代的Java SOAP库中，它们不支持它（来自AXIS2，XFire，CXF）。 因此，只有当您知道需要处理无法做得更好的消费者时，才尝试公开RPC编码服务。 但话说再说，XML RPC可能对这些遗留实现有所帮助。

Answer 3

BiranLy的答案很棒。 我想补充一点，document-vs-RPC也可以归结为实现问题。 我们发现微软是文档偏好的，而我们的基于Java的库是基于RPC的。 无论您选择什么，请确保您了解其他潜在客户也将采取的措施。