REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
当前回答
我的一般规则是,如果你想要一个浏览器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的优点。
其他回答
REST是一种与SOAP完全不同的范例。关于REST的一篇好文章可以在这里找到:我如何向我的妻子解释REST。
如果你没有时间阅读它,这里是一个简短的版本:REST是一个范式的转变,通过关注“名词”,并限制你可以应用于这些名词的“动词”的数量。唯一允许使用的动词是“get”、“put”、“post”和“delete”。这与SOAP不同,SOAP中许多不同的动词可以应用于许多不同的名词(即许多不同的功能)。
对于REST,四个动词映射到相应的HTTP请求,而名词则由url标识。这使得状态管理比SOAP更加透明,在SOAP中,服务器上的状态和客户端上的状态往往不清楚。
但在实践中,大多数情况下,REST通常只是指以JSON返回结果的简单HTTP请求,而SOAP是一种更复杂的API,通过传递XML进行通信。两者都有各自的优点和缺点,但是根据我的经验,我发现REST通常是更好的选择,因为您很少需要从SOAP获得的全部功能。
我也看到了,我想, 它们是针对不同问题的不同工具。
简单对象访问协议(SOAP)标准,一种定义消息体系结构和消息格式的XML语言,被Web服务使用,它包含对操作的描述。WSDL是一种基于xml的语言,用于描述Web服务以及如何访问它们。将运行在SMTP,HTTP,FTP等。需要中间件支持,定义良好的机制来定义服务,如WSDL+XSD, WS-Policy SOAP将返回基于XML的数据,SOAP为安全性和可靠性提供标准
具象状态传输(RESTful) web服务。它们是第二代Web服务。基于rest的web服务通过HTTP而不是基于soap的服务进行通信,并且不需要XML消息或WSDL服务api定义。对于REST,不需要中间件,只需要HTTP支持。WADL标准,REST可以返回XML,纯文本,JSON, HTML等
对于许多类型的客户端来说,使用基于rest的web服务更容易,同时使服务器端能够演进和扩展。客户端可以选择使用服务的部分或全部方面,并将其与其他基于web的服务混合。
REST使用标准HTTP,因此创建客户端和开发api更简单 REST允许许多不同的数据格式,如XML、纯文本、JSON、HTML,而SOAP只允许XML。 REST具有更好的性能和可伸缩性。 休息并且可以缓存,而SOAP不能 内置错误处理,SOAP没有错误处理 REST在PDA和其他移动设备上特别有用。
REST是一种容易与现有网站集成的服务。
SOAP有一组协议,其中提供了安全性和可靠性标准,并与其他符合WS的客户机和服务器进行互操作。 SOAP Web服务(如JAX-WS)在处理异步处理和调用方面很有用。
对于复杂的API, SOAP会更有用。
我认为两者都有自己的位置。在我看来:
SOAP:传统/关键系统和web/web服务系统之间集成的更好选择,在基础层,其中WS-*是有意义的(安全,策略等)。
RESTful:一个更好的网站集成的选择,公共API,在层的顶部(VIEW,即javascript调用uri)。
我写的大多数应用程序都是服务器端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。
我也在关注同样的问题。在我看来,REST实际上是快速和简单的,适用于轻量级调用和响应,并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。
然而,REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止,使用基于REST的web服务似乎是一种更特别的方法,即编写接口来匹配可能的调用。手动发起http请求,然后解析响应。这本身就是危险的。
SOAP的美妙之处在于,一旦WSDL被发布,那么业务就可以构造它们的逻辑主干,从而设置契约,对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而,由于WSDL没有正确地描述REST服务,因此您没有定义的方式来就通信的接口达成一致。
从商业的角度来看,这似乎让沟通变得容易解释和改变,这似乎是个坏主意。
这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议,然而在wiki中,O意味着对象不是面向对象的。它们是不同的东西。
我知道这篇文章很老了,但我认为我应该用我自己的发现来回应。