REST是一种更好的Web服务方法还是SOAP？或者它们是针对不同问题的不同工具？或者这是一个细致入微的问题 - 也就是说,在某些领域比另一个稍微好一点,等等？
赏金编辑:
现在,差不多三年后,我想再次提出这个问题 - 提供奖励以鼓励深入回答.我特别感谢有关这些概念及其与PHP-universe和现代高端Web应用程序的关系的信息.
当我在Hewlett-Packard工作时,我从最初的规范中构建了第一个SOAP服务器之一,包括代码生成和WSDL生成.我建议不要使用SOAP.
首字母缩略词"SOAP"是谎言.它不是简单的,它不是面向对象的,它没有定义Access规则.可以说,这是一项议定书.这是Don Box有史以来最糟糕的规格,这是一个非常壮举,因为他是犯下"COM"的人.
在SOAP中没有什么用处不能通过REST进行传输,JSON,XML甚至是用于数据表示的纯文本.对于传输安全性,您可以使用https.对于身份验证,基本身份验证.对于会话,有cookie.REST版本将更简单,更清晰,运行速度更快,占用带宽更少.
XML-RPC明确定义了请求,响应和错误协议,并且大多数语言都有很好的库.但是,XML比许多任务所需的重.
REST是一种体系结构,SOAP是一种协议.
这是第一个问题.
您可以在REST应用程序中发送SOAP信封.
SOAP本身实际上非常基本和简单,它的WSS-*标准使其非常复杂.
如果您的消费者是其他应用程序和其他服务器,那么今天对SOAP协议有很多支持,移动数据的基础知识实际上是现代IDE中的鼠标单击.
如果您的消费者更可能是RIA或Ajax客户端,那么您可能需要比SOAP更简单的东西,并且更需要客户端(尤其是JSON).
通过HTTP发送的JSON数据包不一定是REST架构,它只是URL的消息.一切都完美可行,但REST成语有关键组件.然而,很容易混淆两者.但仅仅因为你在谈论HTTP请求并不一定意味着你有一个REST架构.您可以拥有一个完全没有HTTP的REST应用程序(介意,这很少见).
因此,如果您的服务器和消费者对SOAP"感到满意",那么SOAP和WSS堆栈可以很好地为您服务.如果您正在做更多临时性的事情并希望更好地与Web浏览器进行交互,那么基于HTTP的一些较轻的协议也可以很好地工作.
REST是与SOAP完全不同的范例.关于REST的好读物可以在这里找到:我如何向我的妻子解释REST.
如果你没有时间阅读它,这里是简短版本:通过专注于"名词",限制你可以应用于那些名词的"动词"的数量,REST是一种范式转换.唯一允许的动词是"get","put","post"和"delete".这与SOAP不同,其中许多不同的动词可以应用于许多不同的名词(即许多不同的功能).
对于REST,四个动词映射到相应的HTTP请求,而名词由URL标识.这使得状态管理比SOAP更加透明,SOAP通常不清楚服务器上的状态和客户端上的状态.
在实践中,虽然大多数情况都会消失,但REST通常仅引用以JSON形式返回结果的简单HTTP请求,而SOAP是通过传递XML进行通信的更复杂的API.两者各有优缺点,但我发现根据我的经验,REST通常是更好的选择,因为您很少需要从SOAP获得的全部功能.
2012年快速下降问题:
REST非常适合的领域是:
有限的带宽和资源.请记住,返回结构实际上是任何格式(开发人员定义).此外,可以使用任何浏览器,因为REST方法使用标准的GET,PUT,POST和DELETE动词.同样,请记住,REST也可以使用大多数现代浏览器目前支持的XMLHttpRequest对象,这增加了AJAX的额外奖励.
完全无国籍的行动. 如果需要继续操作,那么REST不是最好的方法,SOAP可能更适合它.但是,如果您需要无状态CRUD(创建,读取,更新和删除)操作,那么REST就是它.
缓存情况. 如果由于REST方法的完全无状态操作而可以缓存信息,这是完美的.这涵盖了上述三种解决方案中的许多解决方案.
那我为什么还要考虑SOAP呢？同样,SOAP相当成熟且定义明确,并且具有完整的规范.REST方法就是这样一种方法,并且对于开发是开放的,所以如果你有以下内容,那么SOAP是一个很好的解决方案:
异步处理和调用. 如果您的应用程序需要有保证的可靠性和安全性,那么SOAP 1.2提供了额外的标准来确保这种类型的操作.像WSRM - WS-Reliable Messaging这样的东西.
正式合同. 如果双方(提供者和消费者)必须就交换格式达成一致,那么SOAP 1.2为这种类型的交互提供了严格的规范.
有状态的操作.如果应用程序需要上下文信息和会话状态管理,则SOAP 1.2在WS*结构中具有附加规范以支持这些内容(安全性,事务,协调等).相比之下,REST方法将使开发人员构建这个自定义管道.
http://www.infoq.com/articles/rest-soap-when-to-use-each
SOAP目前具有更好工具的优势,它们将为服务层生成大量样板代码,并从任何给定的WSDL生成客户端.
REST更简单,因此更容易维护,是Web架构的核心,允许更好的协议可见性,并且已被证明可以按照WWW本身的规模进行扩展.有些框架可以帮助您构建REST服务,比如Ruby on Rails,有些甚至可以帮助您编写客户端,比如ADO.NET Data Services.但在大多数情况下,缺乏工具支持.
SOAP从工具角度来看很有用,因为WSDL很容易被工具使用.因此,您可以使用您喜欢的语言为您生成Web服务客户端.
REST可以很好地与AJAX网页配合使用.如果您保持简单的请求,您可以直接从您的JavaScript进行服务调用,这非常方便.尽量避免在响应XML中使用任何名称空间,我已经看到浏览器会阻塞这些名称空间.所以,xsi:type可能不适合你,没有过于复杂的XML Schema.
REST往往也有更好的性能.生成REST响应的代码的CPU要求往往低于SOAP框架所展示的要求.而且,如果您在服务器端排列了XML生成器,则可以有效地将XML流式传输到客户端.所以,想象一下你正在读取数据库游标行.在读取行时,将其格式化为XML元素,然后将其直接写入服务使用者.这样,在开始编写XML输出之前,您不必收集内存中的所有数据库行 - 您可以同时读取和写入.查看新颖的模板引擎或XSLT,以使流程适用于REST.
另一方面,SOAP倾向于由工具生成的服务生成为一个大blob,然后才写入.这不是一个绝对的事实,请注意,有一些方法可以从SOAP中获取流特性,例如使用附件.
我的决策过程如下:如果我希望我的服务能够被消费者轻松加工,我写的消息将是中小型(10MB或更少),我不介意烧掉一些额外的CPU在服务器上循环,我使用SOAP.如果我需要在Web浏览器上为AJAX服务,或者我需要流式传输,或者我的响应是巨大的,我会去REST.
最后,围绕SOAP建立了许多很好的标准,比如WS-Security和获取有状态的Web服务,如果你使用正确的工具,你可以插入它们.这种东西真的有所作为,可以帮助你满足一些毛茸茸的要求.
我知道这是一个老问题,但我必须发布我的答案 - 也许有人会觉得它很有用.我无法相信有多少人推荐REST而不是SOAP.我只能假设这些人不是开发人员,或者从未实际实现任何合理大小的REST服务.实现REST服务比实现SOAP服务需要更长的时间.最后,它也变得更加混乱.以下是我99%选择SOAP的原因:
1)实现REST服务比实现SOAP服务花费的时间更长.所有现代语言/框架/平台都存在用于读取WSDL并输出代理类和客户端的工具.实现REST服务是手工完成的 - 通过阅读文档来实现这一点.此外,在实现这两个服务时,您必须"猜测"管道中将返回的内容,因为没有真正的架构或参考文档.
2)为什么要编写一个返回XML的REST服务？唯一的区别是,使用REST,您不知道每个元素/属性所代表的类型 - 您可以自己实现它,并希望有一天字符串不会出现在您认为总是为int的字段中.SOAP使用WSDL定义数据结构,因此这是一个明智的选择.
3)我听说过使用SOAP你有SOAP信封的"开销".在这个时代,我们真的需要担心少数几个字节吗？
4)我听说过用REST可以将URL弹出到浏览器中并查看数据.当然,如果您的REST服务使用简单或无需身份验证.例如,Netflix服务使用OAuth,它要求您在提交请求之前对事物进行签名和编码.
5)为什么我们需要每个资源的"可读"URL？如果我们使用工具来实现服务,我们真的关心实际的URL吗？
需要我继续吗？
我编写的大多数应用程序是服务器端C#或Java,或WinForms或WPF中的桌面应用程序.这些应用程序往往需要比REST提供的更丰富的服务API.另外,我不想花费超过几分钟的时间来创建我的Web服务客户端.WSDL处理客户端生成工具允许我实现我的客户端并继续增加业务价值.
现在,如果我为一些javascript ajax调用显式编写Web服务,它可能在REST中; 只是为了了解客户端技术并利用JSON.在我看来,从javascript使用的Web服务API可能不应该非常复杂,因为这种类型的复杂性似乎更好地处理服务器端.
话虽如此,有一些用于javascript的SOAP客户端; 我知道jQuery有一个.因此,SOAP 可以从javascript中利用; 只是不如返回JSON字符串的REST服务那么好.因此,如果我有一个我想要足够复杂的Web服务,它对于任意数量的客户端技术和用途都是灵活的,那么我将使用SOAP.
我建议你首先使用REST - 如果你使用Java,请查看JAX-RS和Jersey实现.REST更加简单,易于在多种语言中互操作.
正如其他人在这个帖子中所说的那样,SOAP的问题在于其他WS-*规范进入时的复杂性,如果你误入WSDL,XSD,SOAP,WS-Addressing等错误的部分,就会出现无数的互操作问题.
判断REST v SOAP争论的最好方法是在互联网上看 - 几乎所有网络空间中的大玩家,谷歌,亚马逊,ebay,twitter等都倾向于使用和优先于SOAP的RESTful API.
使用REST的另一个好方法是,您可以在Web应用程序和REST前端之间重用大量代码和基础结构.例如,使用JAX-RS和隐式视图等框架渲染HTML与XML而不是资源的JSON通常非常容易 - 而且使用Web浏览器很容易使用RESTful资源
我敢肯定Don Box创建了SOAP作为一个笑话 - "看起来你可以通过网络调用RPC方法",今天当他意识到它变成了一个臃肿的网络标准噩梦时呻吟:-)
REST很好,很简单,在任何地方实现(比标准更"标准")快速简便.使用REST.
我认为两者都有自己的位置.在我看来:
SOAP:传统/关键系统与Web/Web服务系统之间的集成的更好选择,在基础层上,WS-*有意义(安全性,策略等).
RESTful:使用公共API在网页顶层(VIEW,即javascripts调用URI)之间进行集成的更好选择.
没有提到的一件事是SOAP信封可以包含标题和正文部分.这使您可以使用XML的完整表现力来发送和接收带外信息.据我所知,REST限制你使用HTTP标头和结果代码.
(otoh,你可以使用带有REST服务的cookie来发送"标题"类型的带外数据吗？)
不要忽视XML-RPC.如果您只是在轻量级解决方案之后,那么对于一个可以在几页文本中定义并以少量代码实现的协议,可以说很多.XML-RPC已存在多年,但已经过时了一段时间 - 但极简主义的吸引力似乎给了它最近的复兴.
回答2012年更新(通过第二个赏金)问题,并审查今天的结果(其他答案).
关于SOAP 1.2,与"REST"进行比较时的优缺点......好吧,自2007年以来, 您可以使用WSDL描述REST Web服务,并使用SOAP协议......也就是说,如果您的工作稍微努力一点,那么W3C的所有标准都是Web服务协议栈可以是REST!
这是一个很好的起点,因为我们可以想象一个场景,其中暂时避免所有的哲学和方法论讨论.我们可以在技术上将"SOAP-REST"与类似服务中的"NON-SOAP-REST"进行比较,
SOAP-REST(="REST-SOAP"):如L.Mandel所示,WSDL2可以描述REST Web服务,如果我们假设示例XML可以包含在SOAP中,那么所有实现都将是"SOAP-REST" .
非SOAP-REST:任何不能成为SOAP的REST Web服务......也就是说,"90%"的知名REST示例.有些人不使用XML(例如典型的AJAX REST使用JSON),有些使用其他XML结构,没有SOAP标头或规则.PS:为了避免非正式性,我们可以在比较中假设REST级别2.
当然,为了在概念上进行比较,将"NON-REST-SOAP"与"NON-SOAP-REST"进行比较,作为不同的建模方法.因此,完成此Web服务分类:
NON-REST-SOAP:任何不能成为REST的SOAP Web服务......也就是说,"90%"的知名SOAP示例.
非REST-NEITHER-SOAP:是的,"Web服务建模"的世界包含其他东西(例如XML-RPC).
比较可比较的东西:SOAP-REST和NON-SOAP-REST.
解释一些术语,
合同稳定性:适用于各种合同(如"书面协议"),
通过使用标准:W3C堆栈的所有级别 都是相互兼容的.另一方面,REST不是W3C或ISO标准,也没有关于服务外围设备的规范化细节.所以,正如我,@ DaveWoldrich(20票),@ cynicalman(5),@ Exitos(0)之前所说,在需要标准的环境中,你需要SOAP.
通过使用最佳实践:W3C堆栈实现的"冗长方面" ,翻译相关的人/法律/法律协议.
稳健性:SOAP结构和标头的安全性.通过metada通信(具有完整的XML表达能力)和验证,您可以针对任何变化或噪音制定"保险政策".
SOAP具有"事务可靠性(......)处理通信故障.SOAP对重试逻辑有更多的控制,因此可以提供更多的端到端可靠性和服务保证",E.Terman.
按人气排序专业人士,
更好的工具(约70票):SOAP目前具有更好的工具优势,自2007年至2012年,因为它是一个定义明确且被广泛接受的标准.见@MarkCidade(27票),@ DaveWoldrich(20),@ JoshM(13),@ TravisHeseman(9).
标准符合性(25票):正如我,@ DaveWoldrich(20票),@ cynicalman(5),@ Exitos(0)之前所说,在需要标准的环境中,你需要SOAP.
健壮性:SOAP标题的保险,@ JohnSaunders(8票).
SOAP结构更复杂(超过300票):这里的所有答案以及关于"SOAP vs REST"的来源都表现出对SOAP冗余和复杂性的某种程度的不满.这是形式验证要求(见下文)和稳健性(见上文)的自然结果."REST NON-SOAP"(和XML-RPC,SOAP发起者)可以更简单和非正式.
使用微小服务(约50票)时,"唯一的XML"限制是一个性能障碍:请参阅json.org/xml和这个问题,或者另一个问题.这一点由@toluju(41)和其他人展示.
PS:由于JSON不是IETF标准,但我们可以考虑网络软件社区的事实标准.
现在,我们可以使用NON-SOAP-REST比较添加SOAP-NON-REST,并解释何时更好地使用SOAP:
需要标准和稳定的合同(参见"PROS"部分).PS:查看@saille描述的典型"B2B标准需求".
需要工具(参见"PROS"部分).PS:标准,以及正式验证的存在(见下文),是工具自动化的重要问题.
并行繁重处理(参见下面的"上下文/基础"部分):使用更大和/或更慢的进程,无论SOAP的复杂程度如何,可靠性和稳定性都是最佳投资.
需要更高的安全性:当需要超过HTTPS,并且您确实需要其他功能来保护时,SOAP是更好的选择(请参阅@Bell,32票)."沿着比请求/响应更复杂的路径或通过不涉及HTTP的传输发送消息",S.Seely.XML是一个核心问题,为XML加密,XML签名和XML规范化提供标准,并且只有使用SOAP,您才能通过广为接受的WS-Security标准将这些机制嵌入到消息中.
需要更多的灵活性(更少的限制):SOAP不需要与URI完全对应; 没有限制到HTTP; 不需要限制为4个动词.正如@TravisHeseman(9票)所说,如果你想要"灵活使用任意数量的客户端技术和用途",请使用SOAP.
PS:请记住,XML比JSON(等人)更具普遍性和表现力.
需要进行正式验证:了解W3C堆栈使用正式方法很重要,REST更加非正式.您的WSDL(正式语言)服务描述是 Web服务接口的正式规范,SOAP是一个可靠的协议,可接受所有可能的WSDL处方.
CONTEXT
评估趋势是必要的历史观点.对于这个主题,10或15年的视角......
在W3C标准化之前,存在一些无政府状态.很难用不同的框架实现可互操作的服务,并且实现公司之间可互操作的东西更加困难,昂贵和耗时.在W3C栈标准已经一盏灯,为套复杂的Web服务互操作北部.
对于日常工作,比如实施AJAX,SOAP很重要......因此,对简单方法的需求需要选择一个新的理论框架......以及像Google,Amazon这样的大型"Web软件播放器"雅虎等人选择了最好的替代方案,即REST方法.在这种情况下,REST概念是作为"竞争框架"而来的,而今天(2012年),这种替代方案是程序员事实上的标准.
在并行计算的上下文中,Web服务提供并行子任务; 和SOAP一样,协议可确保良好的同步和通信.不是"任何任务":Web服务可以归类为
粗粒度和令人尴尬的并行性.
随着任务变得越来越大,它变得不那么重要的"复杂性辩论",并且变得更加相关的沟通的稳健性和合同的可靠性.
它很细致.
如果您需要让其他系统与您的服务接口,那么很多客户都会对SOAP感到满意,因为您拥有合同,WSDL和SOAP标准的"验证"层.
对于调用系统的日常系统,我认为在简单的HTML调用时,SOAP会带来很多不必要的开销.
我看的是同样的,我认为, 它们是针对不同问题的不同工具.
简单对象访问协议(SOAP)标准是定义消息体系结构和消息格式的XML语言,由Web服务使用,它包含操作的描述.WSDL是一种基于XML的语言,用于描述Web服务以及如何访问它们.将运行在SMTP,HTTP,FTP等上.需要中间件支持,定义良好的机制来定义WSDL + XSD等服务,WS-Policy SOAP将返回基于XML的数据SOAP提供安全性和可靠性标准
代表性状态转移(RESTful)Web服务.它们是第二代Web服务.RESTful Web服务,通过HTTP进行通信而不是基于SOAP的服务,并且不需要XML消息或WSDL服务API定义.对于REST,不需要中间件只需要HTTP支持.WADL标准,REST可以返回XML,纯文本,JSON,HTML等
许多类型的客户端更容易使用RESTful Web服务,同时使服务器端能够发展和扩展.客户可以选择使用服务的部分或全部方面,并将其与其他基于Web的服务混搭.
REST使用标准HTTP,因此创建客户端,开发API非常简单
REST允许许多不同的数据格式,如XML,纯文本,JSON,HTML,因为SOAP只允许XML.
REST具有更好的性能和可伸缩性.
休息,可以缓存,SOAP不能
SOAP没有错误处理的内置错误处理
REST特别适用于PDA和其他移动设备.
REST是服务易于与现有网站集成.
SOAP具有一组协议,这些协议提供安全性和可靠性标准,并与其他符合WS的客户端和服务器进行互操作.SOAP Web服务(例如JAX-WS)在处理异步处理和调用时很有用.
对于Complex API,SOAP将更有用.
REST是Roy Fielding发明的架构,在他的论文" 建筑风格"和"基于网络的软件架构设计"中有所描述.Roy也是HTTP的主要作者- 通过万维网定义文档传输的协议.HTTP是一种RESTful协议.当开发人员谈论"使用REST Web服务"时,说"使用HTTP"可能更准确.
SOAP是一种基于XML的协议,它在HTTP请求/响应中进行隧道传输,因此即使您使用SOAP,也使用REST.关于SOAP是否为基本HTTP添加任何重要功能存在争议.
在创作Web服务之前,我建议学习HTTP.您可以使用规范中已定义的功能来实现您的要求,因此不需要其他协议.
我正在看同样的问题.在我看来,实际上REST快速简单,适用于轻量级调用和响应,非常适合调试(比将URL抽入浏览器并查看响应更好).
然而,REST似乎倒下的地方在于它不是标准(尽管它由标准组成).大多数编程库都有一种检查WSDL的方法,以自动生成使用基于SOAP的服务所需的客户端代码.迄今为止,基于REST的Web服务的使用似乎是一种编写接口以匹配可能的调用的更加特殊的方法.制作手动http请求然后解析响应.这本身就很危险.
SOAP的优点在于,一旦发布了WSDL,那么业务'可以构建他们的逻辑aorund,设置契约对接口的任何更改都将改变wsdl.没有任何空间可供使用.您可以根据该WSDL验证所有请求.但是,由于WSDL没有正确描述REST服务,因此您没有明确的方式来同意通信接口.
从商业角度来看,这似乎使得沟通对解释和变革持开放态度,这似乎是一个坏主意.
这个主题中的顶部"答案"似乎表示SOAP代表面向对象的简单访问协议,但是在Wiki中,O表示对象而不是面向对象.他们是不同的东西.
我知道这篇文章很老,但我想我应该回答我自己的发现.
这是一个很好的问题......我不想让你误入歧途,所以我会像你一样对别人的答案持开放态度.对我来说,它实际上取决于开销成本以及API的用途.我更喜欢在创建客户端软件时使用Web服务,但我不喜欢SOAP的重量.我相信,REST的重量较轻,但我不喜欢从客户的角度来看它的工作量差不多.
我很好奇别人的想法.
收听此播客以了解相关信息.如果你想在不听的情况下知道答案,那么OK,它的REST.但我真的建议听.
我的一般规则是,如果您希望浏览器Web客户端直接连接到服务,那么您应该使用REST.如果要在后端服务之间传递结构化数据,请使用SOAP.
SOAP有时候很难设置,对于简单的Web客户端和服务器数据交换来说往往有点过分.不幸的是,我见过(并从中学到的)大多数简单的编程示例在某种程度上重新强化了这种看法.
也就是说,当您开始将多个SOAP服务组合在一起作为由数据工作流驱动的更大流程(思考企业软件)的一部分时,SOAP真的很棒.这是许多SOAP编程示例无法传达的东西,因为执行某些操作的简单SOAP操作(例如获取股票的价格)通常过于复杂,除非它在提供机器的上下文中呈现可读的API,详细说明具有输入和输出的设置数据格式的特定功能,而这些格式又由更大的进程编写脚本.
在某种程度上,这是令人遗憾的,因为它确实给SOAP带来了不好的声誉,因为如果不在最终产品的使用方式的完整背景下展示SOAP,很难展示SOAP的优势.
京公网安备 11010802040832号 | 京ICP备19059560号-6 