REST是进行Web服务的更好方法还是SOAP? 还是针对不同问题的不同工具? 还是这是一个细微的问题-也就是说,在某些领域中,一个领域比另一个领域要好一些吗?

我特别希望了解有关这些概念及其与PHP宇宙以及现代高端Web应用程序的关系的信息。

===============>>#1 票数:560

当我在惠普工作时,我根据最初的规范构建了第一批SOAP服务器,包括代码生成和WSDL生成。 我不建议对任何东西使用SOAP。

首字母缩写词“ SOAP”是谎言。 它不是简单的,不是面向对象的,它没有定义访问规则。 可以说,它是一个协议。 这是Don Box有史以来最糟糕的规格,这确实是一项壮举,因为他是实施“ COM”的人。

在SOAP中,没有什么可以用REST进行传输,JSON,XML甚至纯文本进行数据表示的方法有用。 为了传输安全,可以使用https。 对于身份验证,请使用基本身份验证。 对于会话,有cookie。 REST版本将更简单,更清晰,运行速度更快并且使用的带宽更少。

XML-RPC清楚地定义了请求,响应和错误协议,并且对于大多数语言都有不错的库。 但是,XML比许多任务所需的重。

===============>>#2 票数:198

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的较轻协议也可以很好地工作。

===============>>#3 票数:102

REST是与SOAP根本不同的范例。 可以在这里找到关于REST的不错的阅读: 我如何向妻子解释REST

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

对于REST,这四个动词映射到相应的HTTP请求,而名词由URL标识。 这使得状态管理要比SOAP中的透明得多,后者通常不清楚服务器上的状态是什么,客户端上的状态是什么。

在实践中,尽管大多数情况都消失了,并且REST通常仅指的是以JSON返回结果的简单HTTP请求,而SOAP是通过传递XML进行通信的更为复杂的API。 两者都有其优点和缺点,但是根据我的经验,REST通常是更好的选择,因为您几乎不需要SOAP的全部功能。

===============>>#4 票数:59

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

===============>>#5 票数:44

SOAP当前具有更好的工具的优势,它们将为服务层生成大量的样板代码,并从任何给定的WSDL生成客户端。

REST更简单,因此更易于维护,它是Web体系结构的核心,允许更好的协议可见性,并且已证明可以根据WWW本身的大小进行扩展。 那里的一些框架可以帮助您构建REST服务,例如Ruby on Rails,甚至可以帮助您编写客户端,例如ADO.NET数据服务。 但是在大多数情况下,缺少工具支持。

===============>>#6 票数:40

从工具的角度来看,SOAP很有用,因为WSDL很容易被工具使用。 因此,您可以使用自己喜欢的语言为您生成Web Service客户端。

REST在AJAX的网页中表现良好。 如果您的请求保持简单,则可以直接从JavaScript进行服务调用,这非常方便。 尽量不要在响应XML中包含任何名称空间,我已经看到浏览器对此感到烦恼。 因此,xsi:type可能对您不起作用,也没有过于复杂的XML模式。

REST也往往具有更好的性能。 生成REST响应的代码对CPU的要求往往低于SOAP框架所显示的。 而且,如果您在服务器端排列了XML生成鸭子,则可以有效地将XML流传输到客户端。 因此,假设您正在读取数据库游标的行。 读取行时,将其格式化为XML元素,然后将其直接写出给服务使用者。 这样,您不必在开始编写XML输出之前就收集内存中的所有数据库行,您可以同时进行读取和写入。 研究新颖的模板引擎或XSLT,以使流工作于REST。

另一方面,SOAP倾向于由工具生成的服务作为一个大对象来生成,然后才被编写。 请注意,这不是一个绝对的事实,有很多方法可以从SOAP中获得流特征,例如使用附件。

我的决策过程如下:如果我希望消费者可以轻松地使用我的服务,并且我写的消息将是中小型的(10MB或更小),并且我不介意消耗一些额外的CPU在服务器上循环,我使用SOAP。 如果我需要在Web浏览器上为AJAX服务,或者需要传输的内容,或者我的响应很大,我可以使用REST。

最后,围绕SOAP建立了许多很棒的标准,例如WS-Security和有状态的Web服务,如果使用正确的工具,则可以插入这些标准。 这种东西确实有所作为,可以帮助您满足一些繁琐的要求。

===============>>#7 票数:29

我知道这是一个老问题,但是我必须发布答案-也许有人会觉得有用。 我不敢相信有多少人推荐基于SOAP的REST。 我只能假设这些人不是开发人员,或者从未实际实现任何合理规模的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吗?

我需要继续吗?

===============>>#8 票数:19

我编写的大多数应用程序都是服务器端C#或Java,或者是WinForms或WPF中的桌面应用程序。 这些应用程序往往需要比REST可以提供的功能更丰富的服务API。 另外,我不想花太多时间来创建我的Web服务客户端。 WSDL处理客户端生成工具使我能够实现我的客户端并继续增加业务价值。

现在,如果我正在为某些javascript ajax调用显式编写Web服务,则它可能在REST中。 只是为了了解客户端技术并利用JSON。 在我看来,从javascript使用的Web服务API可能不会很复杂,因为这种复杂性似乎可以在服务器端更好地处理。

如此说来,有一些javascript的SOAP客户端; 我知道jQuery有一个。 be leveraged from javascript; 因此, 从javascript中利用SOAP。 只是不如返回JSON字符串的REST服务好。 因此,如果我想拥有足够复杂的Web服务,使其对于任意数量的客户端技术和用途都具有灵活性,那么我将使用SOAP。

===============>>#9 票数:17

我建议您先使用REST-如果您使用Java,请查看JAX-RS和Jersey实现。 REST在许多语言中都非常简单且易于互操作。

就像其他人在该线程中所说的那样,SOAP的问题是当其他WS- *规范出现时它的复杂性,如果您误入WSDL,XSD,SOAP,WS-Addressing等错误的部分,则会存在无数互操作问题。

判断REST v SOAP争论的最好方法是在Internet上看-几乎所有网络领域的大公司,如Google,Amazon,ebay,twitter等,都倾向于使用RESTful API而不是SOAP API。

使用REST的另一种不错的方法是,您可以在Web应用程序和REST前端之间重用大量代码和基础结构。 例如,使用JAX-RS和隐式视图之类的框架,通常可以非常轻松地呈现HTML,XML,JSON的资源,此外,还可以轻松地使用Web浏览器处理RESTful资源

===============>>#10 票数:16

我确信Don Box开个玩笑就是说创建SOAP-“看起来您可以在网上调用RPC方法”,如今,当他意识到Web标准已成为肿的噩梦时,他吟了:-)

REST很好,简单,可在任何地方快速实现(比标准更“标准”)。 使用REST。

===============>>#11 票数:15

我认为两者都有自己的位置。 在我看来:

SOAP :在WS- *有意义的基础层(安全性,策略等)上,是遗留/关键系统与Web / Web服务系统之间集成的更好选择。

RESTful :更好的选择,可以在网站的顶层TOP(视图,即javascript调用URI)上与公共API进行网站之间的集成。

===============>>#12 票数:13

尚未提及的一件事是,SOAP信封可以包含标头和主体部分。 这使您可以使用XML的完整表达能力来发送和接收带外信息。 据我所知,REST将您限制为HTTP标头和结果代码。

(otoh,您可以将cookie与REST服务一起使用来发送“标头”类型的带外数据吗?)

===============>>#13 票数:10

回答2012年更新的问题(第二个赏金),并查看今天的结果(其他答案)。


SOAP的优缺点

关于SOAP 1.2,与“ REST”进行比较时的优缺点...从2007年开始, 您可以使用WSDL和SOAP协议来描述REST Web服务 ...也就是说,如果您更加努力,则所有W3C标准Web服务协议栈可以是REST

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

  • SOAP-REST (=“ REST-SOAP”):如L.Mandel所示 ,WSDL2可以描述REST Web服务,并且,如果我们假设可以将示例XML封装在SOAP中,则所有实现都将是“ SOAP-REST” 。

  • NON-SOAP-REST :不能是SOAP的任何REST Web服务...也就是说,众所周知的REST示例中的“ 90%”。 有些不使用XML(例如,典型的AJAX REST使用JSON代替),有些则使用其他XML结构,而没有SOAP标头或规则。 PS:为避免非正式性,我们可以在比较中假设REST级别2

当然,要在概念上进行比较,请将“ NON-REST-SOAP”与“ NON-SOAP-REST”进行比较,以作为不同的建模方法。 因此,完成以下Web服务分类:

  • NON-REST-SOAP :不能是REST的任何SOAP Web服务...也就是说,众所周知的SOAP示例中的“ 90%”。

  • NON-REST-NEITHER-SOAP :是的,“ Web服务建模”的范围包括其他内容(例如XML-RPC )。

REST协议中的SOAP

比较可比的东西: SOAP-RESTNON-SOAP-REST

优点

解释一些术语,

  • 合同稳定性 :适用于各种合同(如“书面协议”),

    • 通过使用标准设备W3C堆栈的所有级别都是相互兼容的。 另一方面,REST不是W3C或ISO标准,也没有有关服务外围设备的规范化细节。 因此,正如 @DaveWoldrich(20票),@ cynicalman(5),@ Exitos(0)之前所说,在需要标准的环境中,您需要SOAP。

    • 通过使用最佳实践W3C堆栈实现的“详细方面”,翻译相关的人类/法律/司法协议。

  • 健壮性 :SOAP结构和标头的安全性。 使用metada通信(具有XML的完整表达能力)和验证,您将拥有针对任何更改或干扰的“保险政策”。
    SOAP具有“交易可靠性(...)处理通信故障。SOAP具有更多围绕重试逻辑的控制,因此可以提供更多的端到端可靠性和服务保证”, E。Terman

按受欢迎程度对专业人士进行排序,

  • 更好的工具 (约70票):从2007年到2012年,SOAP当前具有更好的工具的优势,因为它是一个定义明确且被广泛接受的标准。 参见@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”(以及SOAP的发起者 XML-RPC)可以更加简单和非正式。

  • 使用微型服务(约50票)时,“仅XML”限制是性能障碍 :请参阅json.org/xml此问题 ,或另一个 @toluju(41)等显示了这一点。
    PS:因为JSON不是IETF标准 ,但我们可以考虑将其作为Web软件社区的事实上的标准


使用SOAP建模服务

现在,我们可以将SOAP-NON-RESTNON-SOAP-REST比较添加在一起,并说明何时使用SOAP更好

  • 需要标准和稳定的合同(请参阅“ PROS”部分)。 PS:请参见@saille所描述典型“ B2B标准需求”

  • 需要工具 (请参阅“ PROS”部分)。 PS: 标准形式验证的存在(请参见下文)是工具自动化的重要问题。

  • 并行繁重的处理 (请参见下面的“上下文/基础”部分):对于更大和/或更慢的进程,无论SOAP的复杂性如何,可靠性和稳定性都是最佳的投资。

  • 需要更高的安全性 :当需要的不仅仅是HTTPS且您确实需要其他保护功能时,SOAP是一个更好的选择( 请参阅@Bell ,32票)。 “沿着比请求/响应更复杂的路径或通过不涉及HTTP的传输来发送消息”, S。Seely XML是一个核心问题,提供了XML加密XML签名XML Canonicalization的标准 ,只有使用SOAP,您才能通过公认的WS-Security标准将这些机制嵌入消息中。

  • 需要更大的灵活性 (更少的限制):SOAP不需要与URI完全一致; 不限于HTTP; 不需要限制为4个动词。 正如@TravisHeseman(9票)所说,如果您想要“对于任意数量的客户端技术和用途都可以灵活使用”的内容,请使用SOAP。
    PS:请记住,XML比JSON更通用/更具表现力(等)。

  • 需要形式验证 :了解W3C堆栈使用形式方法 ,而REST更非正式,这一点很重要。 WSDL(一种正式语言 )服务描述是Web服务接口的正式规范 ,而SOAP是一种健壮的协议,可以接受所有可能的WSDL规定。

语境

历史的

评估趋势是必要的历史观点。 对于这个主题,有10到15年的前景...

在W3C标准化之前,存在一些无政府状态。 很难在不同的框架下实现可互操作的服务,而在公司之间实现可互操作的事物则更加困难,昂贵且耗时。 W3C堆栈标准对于复杂的Web服务集的互操作而言是轻而易举的事情。

对于日常任务(例如实施AJAX),SOAP十分繁重...因此,对简单方法的需求需要选择一种新的理论框架...还有像Google,Amazon这样的大型“网络软件开发商”, Yahoo等人选择了最好的替代方法,即REST方法。 在这种情况下,REST概念是作为“竞争框架”出现的,而今天(2012年),这种替代方法已成为程序员的事实上的标准

基础

并行计算的上下文中,Web服务提供并行的子任务。 SOAP之类的协议可确保良好的同步和通信。 不是“任何任务”:Web服务可以分类为
粗糙且令人尴尬的并行性

随着任务的扩大,它变得不再那么重要的“复杂性辩论”,而变得与沟通的健壮性和合同的牢固性息息相关。

===============>>#14 票数:10

不要忽视XML-RPC。 如果您只是想使用一个轻量级的解决方案,那么对于可以在几页文本中定义并以最少的代码实现的协议来说,有很多话要说。 XML-RPC已经存在了很多年,但是已经过时了一段时间-但是极简主义的吸引力似乎正在使它复兴。

===============>>#15 票数:9

我看起来是一样的,我认为它们是解决不同问题的不同工具

简单对象访问协议(SOAP)标准是一种XML语言,定义了消息体系结构和消息格式,由Web服务使用,它包含对操作的描述。 WSDL是一种基于XML的语言,用于描述Web服务以及如何访问它们。 将在SMTP,HTTP,FTP等上运行。需要中间件支持,定义良好的机制以定义WSDL + XSD,WS-Policy SOAP等服务。SOAP将返回基于XML的数据SOAP提供安全性和可靠性标准

代表性状态转移(RESTful)Web服务。 它们是第二代Web服务。 RESTful Web服务比基于SOAP的服务通过HTTP通信,并且不需要XML消息或WSDL服务API定义。 对于REST,不需要中间件,只需要HTTP支持.WADL标准,REST可以返回XML,纯文本,JSON,HTML等

对于许多类型的客户端而言,使用RESTful Web服务更加容易,同时使服务器端能够进行扩展和扩展。 客户可以选择使用服务的某些或所有方面,并将其与其他基于Web的服务混搭。

  1. REST使用标准HTTP,因此创建客户端,开发API更加简单
  2. REST允许许多不同的数据格式,例如XML,纯文本,JSON,HTML,而SOAP仅允许XML。
  3. REST具有更好的性能和可伸缩性。
  4. 休息,可以缓存,SOAP无法
  5. SOAP没有错误处理的内置错误处理
  6. REST对PDA和其他移动设备特别有用。

REST是易于与现有网站集成的服务。

SOAP具有一组协议,这些协议除其他外提供了安全性和可靠性的标准,并且可以与其他符合WS的客户端和服务器进行互操作。 SOAP Web服务(例如JAX-WS)在处理异步处理和调用中很有用。

对于复杂API,SOAP将更加有用。

===============>>#16 票数:9

很细微。

如果您需要让其他系统与您的服务接口,那么很多客户将对SOAP感到满意,这是由于合同,WSDL和SOAP标准具有“验证”层。

对于日常的系统调用,我认为当进行简单的HTML调用时,SOAP会产生很多不必要的开销。

===============>>#17 票数:8

REST是Roy Fielding发明的体系结构,并在其论文《 体系结构样式和基于网络的软件体系结构设计》中进行了描述 Roy还是HTTP的主要作者,该协议定义了通过万维网的文档传输。 HTTP是RESTful协议。 当开发人员谈论“使用REST Web服务”时,说“使用HTTP”可能更准确。

SOAP是基于XML的协议,可在HTTP请求/响应内部进行隧道传输,因此,即使您使用SOAP,也将使用REST。 关于SOAP是否在基本HTTP中添加任何重要功能存在一些争论。

在创作Web服务之前,建议您学习HTTP。 奇怪的是,您的要求可以使用规范中已定义的功能来实现,因此不需要其他协议。

===============>>#18 票数:7

我在看同样的问题。 在我看来,REST实际上是快速,容易的,并且对轻量级的调用和响应非常有用,并且对于调试非常有用(这比将URL注入浏览器并查看响应更好)。

但是,REST似乎失败的原因在于它不是一个标准(尽管它由标准组成)。 大多数编程库都有一种检查WSDL的方法,以自动生成使用基于SOAP的服务所需的客户端代码。 因此,基于REST的Web服务耗时很长,似乎是编写接口以匹配可能的调用的一种更为特殊的方法。 发出手动http请求,然后解析响应。 这本身可能很危险。

SOAP的优点在于,一旦发布WSDL,企业就可以构建其逻辑框架,该逻辑框架规定了合同的任何更改都将更改wsdl。 没有空余的空间。 您可以针对该WSDL验证所有请求。 但是,由于WSDL不能正确描述REST服务,因此您没有在通信接口上达成一致的定义方法。

从业务角度看,这似乎确实使交流容易进行解释和更改,这似乎是一个坏主意。

该线程中最上面的“答案”似乎表明SOAP代表简单的面向对象的访问协议,但是从Wiki看,O表示对象不是面向对象的。 他们是不同的东西。

我知道这篇文章很老,但是我应该以自己的发现回应。

===============>>#19 票数:6

我的一般规则是,如果希望浏览器Web客户端直接连接到服务,则应该使用REST。 如果要在后端服务之间传递结构化数据,请使用SOAP。

有时设置SOAP可能会造成很大的痛苦,并且对于简单的Web客户端和服务器数据交换而言通常过于矫kill过正。 不幸的是,我所看到(并从中学习)的大多数简单编程示例都在某种程度上增强了这种认识。

就是说,当您开始将多个SOAP服务组合在一起时,作为一个由数据工作流驱动的较大流程的一部分(想像企业软件),SOAP确实会发光。 这是许多SOAP编程示例无法传达的,因为执行简单的SOAP操作(例如获取股票价格)通常会因其本身的功能而过于复杂,除非在提供机器的上下文中进行了介绍。可读的API,其中详细说明了特定功能,并为输入和输出设置了数据格式,进而由较大的过程编写了脚本。

从某种程度上来说,这很可悲,因为它确实给SOAP不好的声誉,因为如果不完整地介绍最终产品的使用方式,就很难展示SOAP的优势。

===============>>#20 票数:6

收听此播客以查找答案。 如果您想不听就知道答案,那么可以使用它的REST。 但我确实建议您收听。

===============>>#21 票数:6

这是一个很好的问题...我不想让你误入歧途,所以我和你一样愿意接受其他人的回答。 对我来说,这实际上要归结为开销成本以及API的用途。 在创建客户端软件时,我更喜欢使用Web服务,但是我不喜欢SOAP的重量。 我相信REST的重量较轻,但从客户的角度来看,我几乎不喜欢使用REST。

我对别人的想法很好奇。

===============>>#22 票数:4

SOAP体现了一种面向服务的Web服务方法,其中一种方法(或动词)是与服务交互的主要方式。 REST采用一种面向资源的方法,其中对象(或名词)占据中心位置。

===============>>#23 票数:4

从“ PHP-universe”的意义上讲,对任何高级SOAP的PHP支持都花费了大量时间。 满足基本需求后,您最终将使用http://wso2.com/products/web-services-framework/php/之类的东西,甚至使WS-Security或WS-RM没有内置支持。

我感觉SOAP信封的创建在PHP中非常混乱,它创建命名空间的方式,xsd:nil,xsd:anytype和旧样式的soap服务在SOAP消息中使用SOAP编码(上帝知道有什么不同)。

坚持使用REST可以避免所有麻烦,自从WWW以来,我们就一直在使用REST。 仅当此http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm论文发表时,我们才意识到它显示了我们如何使用HTTP功能来实现RESTFul Services。 HTTP本质上就是REST,这并不意味着仅使用HTTP就可以使您的服务成为RESTFul。

SOAP忽略了HTTP的核心功能,并且将HTTP视为一种传输协议,因此从理论上讲它是独立于传输协议的(实际上,您不是听说过SOAP Action标头的吗?

随着JSON适应性的增加以及HTML5和Javascript逐渐成熟,REST和JSON已成为处理服务的最常见方法。 还定义了JSON模式,并在需要时可与WADL一起用于企业级解决方案(仍处于早期阶段)。

PHP对REST和JSON的支持绝对比其现有的内置SOAP支持要好。

在此处添加一些BUZZ词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规范,这是一个很好的规范,如果想对Enterprise JSON进行适应性思考的人确实需要提供一些类似JSON的功能,例如字段级加密等。

===============>>#24 票数:3

快速点-传输协议和编排;

出于速度,可靠性和安全性的原因,我使用SOAP over TCP,包括协调的机器到机器服务(ESB)和外部服务。 更改服务定义,业务流程会因WSDL更改而引发错误,并且该错误立即显而易见,并且可以重新构建/部署。

不确定您是否可以使用REST进行相同操作-我正在等待纠正或课程! 使用REST,更改服务定义-在返回400(或其他任何值)之前,对此一无所知。

===============>>#25 票数:2

我创建了一个基准来查找其中哪个更快! 我看到这个结果:

对于1000个请求:

  • REST花费了3秒
  • SOAP用了7秒

10,000个请求:

  • REST花费了33秒
  • SOAP花了69秒

1,000,000个请求:

  • REST用了62秒
  • SOAP花了114秒

===============>>#26 票数:2

如果您正在寻找不同系统和语言之间的互操作性,那么我一定会选择REST。 例如,在使SOAP在.NET和Java之间工作时,我遇到了很多问题。

===============>>#27 票数:0

一个古老的问题,但今天仍然有意义。...由于企业领域中有如此多的开发人员仍在使用它。

我的工作涉及设计和开发IoT(物联网)解决方案。 其中包括为与云通信的小型嵌入式设备开发代码。

显然,REST现在已被广泛接受和使用,几乎是Web的事实上的标准,甚至Microsoft都在整个Azure中提供了REST支持。 如果我需要依靠SOAP,那么我就无法做我需要做的事情,对于小型嵌入式设备而言,它太大,笨重且令人讨厌。

REST简单,干净,小巧。 使其非常适合小型嵌入式设备。 当我与向我发送WSDL的Web开发人员一起工作时,我总是大喊大叫。 正如我将要开始的教育运动那样,这为什么行不通以及为什么他们必须学习REST。

===============>>#28 票数:0

1.根据我的经验。 我想说REST让您可以选择访问已构建的URL。 例如->在Google中搜索单词。 该URL可用作REST的Web服务。 在SOAP中,您可以创建自己的Web服务并通过SOAP客户端访问它。

  1. REST支持文本,JSON,XML格式。 因此,在两个应用程序之间进行通信时更加通用。 SOAP只支持XML格式的消息通信。

  ask by user13276 translate from so

未解决问题?本站智能推荐:

1回复

用于大量事务和大数据项目的REST或SOAP

项目要求: 我需要构建一个Web服务,它将接收大量的文本数据,从几千字节到10兆字节,但平均徘徊在几百千字节左右。 会有大量的交易,我想通过身份验证,SSL以及最终的一些加密来保护服务。 如果可能的话,我希望该服务支持XML和JSON,我想使用开源工具构建它 - 很可能是PHP /
1回复

关于基于XML的API,REST和SOAP with Python的任何书籍和/或教程都不错? [关闭]

关于基于XML的API,REST,Python的SOAP,有哪些好的书籍和/或教程?
1回复

如何在C#的RESTful服务中发送和接收soap + xml

我想用C#编写用于企业移动设备管理的RESTful Web服务,以发布下面由Microsoft定义的请求显示: POST请求信息: 回复信息 我想知道如何在Web服务中为POST调用创建WebInvoke方法? 使用下面的原型,我能够发送和接收soap xml,但是不
1回复

什么是Web服务?如何使用它们?

我想了解 到底什么是网络服务 他们如何使用 我所知道的是它们是用SOAP / XML编码的,并且它们是独立于语言的,这意味着我可以用Java编写程序并创建Web服务,并且任何程序的用户都可以调用它。 但我希望进一步了解低级细节。
1回复

如何与网络服务通信

我正在做SOA的最后一年项目。 我需要通过Java编码与Web服务进行通信。 与Web服务通信的最佳方法是什么。 请以任何方式推荐我。 如果可能的话,向我发布教程链接或youtube视频链接。 请。 提前非常感谢您。
5回复

可以为开发Web服务提供哪些陷阱/技巧

希望用PHP开发Web服务(api),为客户提供更轻松的方式来集成我们的平台。 有一些工作流程调用将通过user / pass以及一些报告选项进行验证。 抱歉,我无法发布有关该主题的更多详细信息或代码,我从未开发过Web服务,但有使用SOAP的经验。 现在我还需要提供工作流程的状态
1回复

指示应使用哪个版本的XML模式解码XML Web服务有效载荷的最佳方法是什么?

我主要在REST / XML Web服务API(媒体类型为“ application / vnd.mystuff + xml”)的情况下询问此问题,但是对于基于SOAP的Web服务,该问题可能仍然有效。 如果描述我们的资源/有效负载词汇的XML模式发生了变化,那么我该如何最好地向客户表明他
1回复

如何从现有的基于XML的RESTful服务创建Java Jersey客户端

我习惯于与SOAP Webservices集成,其中wsdl是可访问的,并且可以用于使用wsimport生成java客户端。 我最近获得了一个RESTful端点,它使用XML作为有效负载类型。 到目前为止,我看到没有WADL \\ Swagger YML文件,我可以访问以获取服务的定义。
2回复

适用于Linux上REST和/或SOAP Web服务开发的堆栈/框架[关闭]

我一直在尝试对CentOS / Redhat的REST和SOAP Web服务支持框架进行一些研究,这些框架也能够合理地支持管理Web应用程序以及服务本身。 我们还没有确定REST或SOAP是否是进行服务通信的方式。 通信要求非常简单,因此可能不需要更重的SOAP接口。 (但也不复杂)
2回复

REST与SOAP Web服务[关闭]

我看到,如今,许多新的Web服务都是使用REST风格的体系结构而不是SOAP来实现的。 有什么区别?