REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
当前回答
我也在关注同样的问题。在我看来,REST实际上是快速和简单的,适用于轻量级调用和响应,并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。
然而,REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止,使用基于REST的web服务似乎是一种更特别的方法,即编写接口来匹配可能的调用。手动发起http请求,然后解析响应。这本身就是危险的。
SOAP的美妙之处在于,一旦WSDL被发布,那么业务就可以构造它们的逻辑主干,从而设置契约,对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而,由于WSDL没有正确地描述REST服务,因此您没有定义的方式来就通信的接口达成一致。
从商业的角度来看,这似乎让沟通变得容易解释和改变,这似乎是个坏主意。
这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议,然而在wiki中,O意味着对象不是面向对象的。它们是不同的东西。
我知道这篇文章很老了,但我认为我应该用我自己的发现来回应。
其他回答
我相信Don Box创建SOAP是一个笑话——“看,你可以在web上调用RPC方法”,今天当他意识到它已经成为一个臃肿的web标准的噩梦时,他会呻吟:-)
REST很好,很简单,在任何地方都可以实现(所以它更像是一个“标准”,而不是标准),又快又简单。使用REST。
从“PHP-宇宙”的意义上讲,PHP对任何高级SOAP的支持都很糟糕。一旦您满足了基本需求,您最终将使用类似http://wso2.com/products/web-services-framework/php/的东西,甚至启用没有内置支持的WS-Security或WS-RM。
我觉得在PHP中创建SOAP信封是非常混乱的,它创建命名空间的方式,xsd:nil, xsd:anytype和老式的SOAP服务使用SOAP编码(上帝知道这有什么不同)与SOAP消息。
通过坚持REST来避免所有这些混乱,REST并不是什么大不了的东西,我们从WWW开始就在使用它。直到这篇http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm论文发表后,我们才意识到,它展示了如何使用HTTP功能来实现RESTFul服务。HTTP本质上是REST,这并不意味着仅仅使用HTTP就可以使您的服务RESTFul。
SOAP忽略了HTTP的核心功能,只将HTTP视为传输协议,因此理论上它是独立于传输协议的(实际上并非如此,您听说过SOAP Action报头吗?如果不是现在!)。
随着JSON适应的增加以及HTML5和javascript的成熟,REST和JSON已经成为处理服务的最常见方式。JSON Schema也被定义为可以在需要时与WADL一起用于企业级解决方案(仍处于早期阶段)。
PHP对REST和JSON的支持肯定比现有的内置SOAP支持更好。
在这里添加更多的术语SOA, WOA, ROA
http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/
http://www.scribd.com/doc/15657444/REST-White-Paper
顺便说一下,我非常喜欢SOAP,特别是WS-Security规范,这是一个很好的规范,如果有人在考虑企业JSON适应肯定需要一些类似JSON的东西,比如字段级加密等。
SOAP体现了Web服务的面向服务的方法——在这种方法中,方法(或动词)是与服务交互的主要方式。REST采用面向资源的方法,其中对象(或名词)占据中心位置。
我也在关注同样的问题。在我看来,REST实际上是快速和简单的,适用于轻量级调用和响应,并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。
然而,REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止,使用基于REST的web服务似乎是一种更特别的方法,即编写接口来匹配可能的调用。手动发起http请求,然后解析响应。这本身就是危险的。
SOAP的美妙之处在于,一旦WSDL被发布,那么业务就可以构造它们的逻辑主干,从而设置契约,对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而,由于WSDL没有正确地描述REST服务,因此您没有定义的方式来就通信的接口达成一致。
从商业的角度来看,这似乎让沟通变得容易解释和改变,这似乎是个坏主意。
这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议,然而在wiki中,O意味着对象不是面向对象的。它们是不同的东西。
我知道这篇文章很老了,但我认为我应该用我自己的发现来回应。
我建议您先使用REST——如果您正在使用Java,请查看JAX-RS和Jersey实现。REST更简单,易于在多种语言中进行互操作。
正如其他人在这篇文章中所说,SOAP的问题在于当其他WS-*规范加入时它的复杂性,如果您误入WSDL、xsd、SOAP、WS- addressing等的错误部分,就会出现无数的互操作问题。
判断REST和SOAP之争的最好方法是看看互联网——几乎所有网络领域的大玩家,谷歌、amazon、ebay、twitter等——都倾向于使用并偏爱RESTful api而不是SOAP api。
使用REST的另一个很好的方法是,你可以在web应用程序和REST前端之间重用大量的代码和基础设施。例如,使用JAX-RS和隐式视图等框架,将资源的HTML、XML和JSON呈现出来通常是非常容易的,而且使用web浏览器也很容易处理RESTful资源