REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
当前回答
从工具的角度来看,SOAP很有用,因为工具很容易使用WSDL。因此,您可以用您喜欢的语言为您生成Web服务客户机。
REST在AJAX的网页上表现得很好。如果保持请求的简单性,就可以直接从JavaScript调用服务,这非常方便。尽量避免在响应XML中使用任何名称空间,我看到浏览器在使用这些名称空间时会窒息。因此,xsi:type可能不适合您,没有过于复杂的XML schema。
REST tends to have better performance as well. CPU requirements of the code generating REST responses tend to be lower than what SOAP frameworks exhibit. And, if you have your XML generation ducks lined up on the server side, you can effectively stream XML out to the client. So, imagine you're reading rows of database cursor. As you read a row, you format it as an XML element, and you write that directly out to the service consumer. This way, you don't have to collect all of the database rows in memory before starting to write your XML output - you read and write at the same time. Look into novel templating engines or XSLT to get the streaming to work for REST.
另一方面,SOAP往往是由工具生成的服务生成的一个大blob,然后才编写。请注意,这并不是绝对的事实,有很多方法可以从SOAP中获得流特性,比如使用附件。
我的决策过程如下:如果我想让我的服务易于被消费者使用,并且我编写的消息将是中等到小型的(10MB或更小),并且我不介意在服务器上消耗一些额外的CPU周期,那么我就使用SOAP。如果我需要在web浏览器上使用AJAX,或者我需要进行流式处理,或者我的响应非常大,我就使用REST。
最后,围绕SOAP建立了许多很棒的标准,如WS-Security和获得有状态的Web服务,如果使用正确的工具,可以将它们插入。这类东西真的很重要,可以帮助您满足一些棘手的要求。
其他回答
我也在关注同样的问题。在我看来,REST实际上是快速和简单的,适用于轻量级调用和响应,并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。
然而,REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止,使用基于REST的web服务似乎是一种更特别的方法,即编写接口来匹配可能的调用。手动发起http请求,然后解析响应。这本身就是危险的。
SOAP的美妙之处在于,一旦WSDL被发布,那么业务就可以构造它们的逻辑主干,从而设置契约,对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而,由于WSDL没有正确地描述REST服务,因此您没有定义的方式来就通信的接口达成一致。
从商业的角度来看,这似乎让沟通变得容易解释和改变,这似乎是个坏主意。
这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议,然而在wiki中,O意味着对象不是面向对象的。它们是不同的东西。
我知道这篇文章很老了,但我认为我应该用我自己的发现来回应。
当我在惠普工作时,我根据开发中的原始规范构建了第一批SOAP服务器之一,包括代码生成和WSDL生成。我不建议在任何事情上使用SOAP。
首字母缩写“SOAP”是一个谎言。它不是简单的,它不是面向对象的,它没有定义访问规则。可以说,它是一项议定书。这是Don Box有史以来最糟糕的规格,这是一个相当了不起的壮举,因为他是“COM”的创造者。
SOAP中没有什么有用的东西是REST不能用于传输的,JSON、XML甚至纯文本不能用于数据表示的。为了传输安全,可以使用https协议。对于认证,使用基本认证。对于会话,有cookie。REST版本将更简单、更清晰、运行更快、使用更少的带宽。
XML-RPC清楚地定义了请求、响应和错误协议,并且对于大多数语言都有很好的库。但是,对于许多任务来说,XML比您所需要的要重。
从“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的东西,比如字段级加密等。
快速了解一下2012年的问题:
REST在以下方面发挥了很好的作用:
Limited bandwidth and resources. Remember the return structure is really in any format (developer defined). Plus, any browser can be used because the REST approach uses the standard GET, PUT, POST, and DELETE verbs. Again, remember that REST can also use the XMLHttpRequest object that most modern browsers support today, which adds an extra bonus of AJAX. Totally stateless operations. If an operation needs to be continued, then REST is not the best approach and SOAP may fit it better. However, if you need stateless CRUD (Create, Read, Update, and Delete) operations, then REST is it. Caching situations. If the information can be cached because of the totally stateless operation of the REST approach, this is perfect.That covers a lot of solutions in the above three.
那么我为什么要考虑SOAP呢?同样,SOAP是相当成熟和定义良好的,并且带有完整的规范。REST方法就是这样一种方法,它对开发非常开放,所以如果你具备以下条件,那么SOAP就是一个很好的解决方案:
Asynchronous processing and invocation. If your application needs a guaranteed level of reliability and security then SOAP 1.2 offers additional standards to ensure this type of operation. Things like WSRM – WS-Reliable Messaging. Formal contracts. If both sides (provider and consumer) have to agree on the exchange format then SOAP 1.2 gives the rigid specifications for this type of interaction. Stateful operations. If the application needs contextual information and conversational state management then SOAP 1.2 has the additional specification in the WS* structure to support those things (Security, Transactions, Coordination, etc). Comparatively, the REST approach would make the developers build this custom plumbing.
http://www.infoq.com/articles/rest-soap-when-to-use-each
有一件事没有提到,SOAP信封既可以包含头部,也可以包含主体部分。这使您可以使用XML的完整表达来发送和接收带外信息。据我所知,REST限制你使用HTTP头和结果代码。
(哦,你可以使用cookie和REST服务一起发送“头”类型的带外数据吗?)