REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
当前回答
REST是Roy Fielding发明的一种架构,并在他的论文《架构风格和基于网络的软件架构设计》中进行了描述。Roy也是HTTP协议的主要作者,该协议定义了在万维网上的文档传输。HTTP是RESTful协议。当开发人员谈论“使用REST Web服务”时,可能更准确的说法是“使用HTTP”。
SOAP是一种基于xml的协议,它在HTTP请求/响应中进行隧道传输,因此即使您使用SOAP,您也在使用REST。关于SOAP是否为基本HTTP添加了任何重要的功能存在一些争论。
在创建Web服务之前,我建议学习HTTP。很可能您的需求可以使用规范中已经定义的功能实现,因此不需要其他协议。
其他回答
从工具的角度来看,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——如果您正在使用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资源
我的一般规则是,如果你想要一个浏览器web客户端直接连接到一个服务,那么你可能应该使用REST。如果希望在后端服务之间传递结构化数据,则使用SOAP。
SOAP的设置有时真的很痛苦,对于简单的web客户端和服务器数据交换来说,它通常是多余的。不幸的是,我所见过(并从中学到)的大多数简单编程示例都在某种程度上强化了这种看法。
That said, SOAP really shines when you start combining multiple SOAP services together as part of a larger process driven by a data workflow (think enterprise software). This is something that many of the SOAP programming examples fail to convey because a simple SOAP operation to do something, like fetch the price of a stock, is generally overcomplicated for what it does by itself unless it is presented in the context of providing a machine readable API detailing specific functions with set data formats for inputs and outputs that is, in turn, scripted by a larger process.
在某种程度上,这是可悲的,因为它确实给SOAP带来了坏名声,因为如果不在最终产品如何使用的完整上下文中展示它,就很难展示SOAP的优点。
我认为两者都有自己的位置。在我看来:
SOAP:传统/关键系统和web/web服务系统之间集成的更好选择,在基础层,其中WS-*是有意义的(安全,策略等)。
RESTful:一个更好的网站集成的选择,公共API,在层的顶部(VIEW,即javascript调用uri)。
一个快速点传输协议和编制;
出于速度、可靠性和安全性的考虑,我在TCP上使用SOAP,包括编排的机器对机器服务(ESB)和外部服务。更改服务定义,业务流程会从WSDL更改中引发一个错误,并且它会立即显现出来,并且可以重新构建/部署。
不确定你可以用REST做同样的事情-我等待被纠正或课程! 使用REST,更改服务定义—在返回400(或其他值)之前,没有人知道它。