REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?

我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。


当前回答

我写的大多数应用程序都是服务器端c#或Java,或者WinForms或WPF中的桌面应用程序。这些应用程序往往需要比REST所能提供的更丰富的服务API。另外,我不想在创建web服务客户机上花费超过几分钟的时间。WSDL处理客户端生成工具允许我实现我的客户端并继续添加业务价值。

现在,如果我为一些javascript ajax调用显式地编写web服务,它可能是在REST中;只是为了了解客户端技术和利用JSON。在我看来,从javascript中使用的web服务api可能不应该非常复杂,因为这种类型的复杂性似乎可以更好地处理服务器端。

也就是说,javascript有一些SOAP客户端;我知道jQuery有一个。因此,SOAP可以从javascript中利用;只是不像REST服务返回JSON字符串那样好。因此,如果我有一个web服务,我希望它足够复杂,能够灵活地适应任意数量的客户端技术和用途,那么我会选择SOAP。

其他回答

从工具的角度来看,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服务,如果使用正确的工具,可以将它们插入。这类东西真的很重要,可以帮助您满足一些棘手的要求。

从“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的东西,比如字段级加密等。

1.从我的经验来看。我想说REST让你可以选择访问已经构建好的URL。>一个词搜索谷歌。该URL可以用作REST的web服务。 在SOAP中,您可以创建自己的web服务并通过SOAP客户机访问它。

REST支持文本、JSON、XML格式。因此,两个应用程序之间的通信更加通用。而SOAP仅支持XML格式的消息通信。

回答2012年刷新的问题(通过第二个赏金),并回顾今天的结果(其他答案)。


SOAP的利弊

关于SOAP 1.2,与“REST”相比的优点和缺点…从2007年开始 你可以用WSDL描述REST Web服务, 并使用SOAP协议…也就是说,如果您再努力一点,web服务协议栈的所有W3C标准都可以是REST!

这是一个很好的起点,因为我们可以想象一个场景,在这个场景中,所有的哲学和方法论讨论都暂时被避免了。我们可以在技术上比较类似服务中的“SOAP-REST”和“非SOAP-REST”,

SOAP-REST (="REST-SOAP"): as showed by L.Mandel, WSDL2 can describe a REST webservice, and, if we suppose that exemplified XML can be enveloped in SOAP, all the implementation will be "SOAP-REST". NON-SOAP-REST: any REST web service that can not be SOAP... That is, "90%" of the well-knowed REST examples. Some not use XML (ex. typical AJAX RESTs use JSON instead), some use another XML strucutures, without the SOAP headers or rules. PS: to avoid informality, we can suppose REST level 2 in the comparisons.

当然,为了从概念上进行比较,可以将“NON-REST-SOAP”与“NON-SOAP-REST”作为不同的建模方法进行比较。那么,完成这个web服务分类:

NON-REST-SOAP:任何不能是REST的SOAP web服务…也就是说,“90%”的广为人知的SOAP示例。 NON-REST-NEITHER-SOAP:是的,“web服务建模”的世界包括其他东西(例如XML-RPC)。

REST条件下的SOAP

比较可比较的事物:皂歇和非皂歇。

PROS

解释一些术语,

Contractual stability: for all kinds of contracts (as "written agreements"), By the use of standars: all levels of the W3C stack are mutually compliant. REST, by other hand, is not a W3C or ISO standard, and have no normatized details about service's peripherals. So, as I, @DaveWoldrich(20 votes), @cynicalman(5), @Exitos(0) said before, in a context where are NEED FOR STANDARDS, you need SOAP. By the use of best practices: the "verbose aspect" of the W3C stack implementations, translates relevant human/legal/juridic agreements. Robustness: the safety of SOAP structure and headers. With metada communication (with the full expressiveness of XML) and verification you have an "insurance policy" against any changes or noise. SOAP have "transactional reliability (...) deal with communication failures. SOAP has more controls around retry logic and thus can provide more end-to-end reliability and service guarantees", E. Terman.

按受欢迎程度排序,

更好的工具(~70票):从2007年到2012年,SOAP目前拥有更好的工具的优势,因为它是一个定义良好且被广泛接受的标准。参见@MarkCidade(27票),@DaveWoldrich(20票),@JoshM(13票),@TravisHeseman(9票)。 标准遵从性(25票):正如我,@DaveWoldrich(20票),@愤世嫉俗的人(5票),@Exitos(0票)之前所说,在需要标准的上下文中,您需要SOAP。 健壮性:SOAP头的保险,@JohnSaunders(8票)。

CONS

SOAP strucuture is more complex (more than 300 votes): all answers here, and sources about "SOAP vs REST", manifest some degree of dislike with SOAP's redundancy and complexity. This is a natural consequence of the requirements for formal verification (see below), and for robustness (see above). "REST NON-SOAP" (and XML-RPC, the SOAP originator) can be more simple and informal. The "only XML" restriction is a performance obstacle when using tiny services (~50 votes): see json.org/xml and this question, or this other one. This point is showed by @toluju(41), and others. PS: as JSON is not a IETF standard, but we can consider a de facto standard for web software community.


使用SOAP对服务建模

现在,我们可以添加SOAP- non - rest与非SOAP- rest比较,并解释什么时候使用SOAP更好:

Need for standards and stable contracts (see "PROS" section). PS: see a typical "B2B need for standards" described by @saille. Need for tools (see "PROS" section). PS: standards, and the existence of formal verifications (see bellow), are important issues for the tools automation. Parallel heavy processing (see "Context/Foundations" section below): with bigger and/or slower processes, no matter with a bit more complexity of SOAP, reliability and stability are the best investments. Need more security: when more than HTTPS is required, and you really need additional features for protection, SOAP is a better choice (see @Bell, 32 votes). "Sending the message along a path more complicated than request/response or over a transport that does not involve HTTP", S. Seely. XML is a core issue, offering standards for XML Encryption, XML Signature, and XML Canonicalization, and, only with SOAP you can to embed these mechanisms into a message by a well-accepted standard as WS-Security. Need more flexibility (less restrictions): SOAP not need exact correspondence with an URI; not nedd restrict to HTTP; not need to restrict to 4 verbs. As @TravisHeseman (9 votes) says, if you wanted something "flexible for an arbitrary number of client technologies and uses", use SOAP.PS: remember that XML is more universal/expressive than JSON (et al). Need for formal verifications: important to understand that W3C stack uses formal methods, and REST is more informal. Your WSDL (a formal language) service description is a formal specification of your web services interfaces, and SOAP is a robust protocol that accept all possible WSDL prescriptions.

上下文

历史

要判断趋势,必须有历史的眼光。对于这个问题,10年或15年的展望……

在W3C标准化之前,有一些混乱。很难用不同的框架实现可互操作的服务,而在公司之间实现一些可互操作的东西则更加困难、昂贵和耗时。 W3C堆栈标准一直是复杂web服务集互操作的明灯。

对于日常的任务,比如实现AJAX, SOAP很繁重……因此,需要简单的方法,需要选择一个新的理论框架…而大的“网络软件玩家”,如谷歌、亚马逊、雅虎等,选出了最佳的替代方案,那就是REST方法。在这种情况下,REST概念作为一个“竞争性框架”出现了,并且,今天(2012年),这个替代方案已经成为程序员的事实上的标准。

基金会

在并行计算环境下,web服务提供并行子任务;和协议,如SOAP,确保良好的同步和通信。不是“任何任务”:web服务可以被分类为 粗粒度和令人尴尬的并行。

随着任务变得越来越大,“复杂性争论”变得不那么重要,而与通信的稳健性和合同的稳固性更加相关。

REST是一种与SOAP完全不同的范例。关于REST的一篇好文章可以在这里找到:我如何向我的妻子解释REST。

如果你没有时间阅读它,这里是一个简短的版本:REST是一个范式的转变,通过关注“名词”,并限制你可以应用于这些名词的“动词”的数量。唯一允许使用的动词是“get”、“put”、“post”和“delete”。这与SOAP不同,SOAP中许多不同的动词可以应用于许多不同的名词(即许多不同的功能)。

对于REST,四个动词映射到相应的HTTP请求,而名词则由url标识。这使得状态管理比SOAP更加透明,在SOAP中,服务器上的状态和客户端上的状态往往不清楚。

但在实践中,大多数情况下,REST通常只是指以JSON返回结果的简单HTTP请求,而SOAP是一种更复杂的API,通过传递XML进行通信。两者都有各自的优点和缺点,但是根据我的经验,我发现REST通常是更好的选择,因为您很少需要从SOAP获得的全部功能。