REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
REST是更好的Web服务方法还是SOAP?或者它们是针对不同问题的不同工具?或者这是一个微妙的问题——也就是说,一个人在某些领域比另一个人稍微好一点,等等?
我尤其希望了解这些概念以及它们与php世界以及现代高端网络应用程序的关系。
当前回答
我创建了一个基准,以找出它们中哪一个更快! 我看到了这样的结果:
对于1000个请求:
休息用时3秒 SOAP耗时7秒
对于10,000个请求:
休息用时33秒 SOAP用时69秒
对于1,000,000个请求:
休息用时62秒 SOAP耗时114秒
其他回答
这是微妙的。
如果您需要让其他系统与您的服务进行接口,那么由于您使用契约、WSDL和SOAP标准所拥有的“验证”层,许多客户端将更乐于使用SOAP。
对于日常系统对系统的调用,我认为SOAP是很多不必要的开销,而简单的HTML调用就可以了。
这是个好问题……我不想让你误入歧途,所以我和你一样愿意接受别人的答案。对我来说,这实际上归结于开销成本和API的使用。在创建客户端软件时,我更喜欢使用web服务,但是我不喜欢SOAP的重量。我相信REST的重量更轻,但我不太喜欢从客户的角度使用它。
我很好奇别人是怎么想的。
我也在关注同样的问题。在我看来,REST实际上是快速和简单的,适用于轻量级调用和响应,并且非常适合调试(还有什么比将URL注入浏览器并查看响应更好的呢)。
然而,REST的不足之处在于它不是一个标准(尽管它由标准组成)。大多数编程库都有一种检查WSDL以自动生成消费基于SOAP的服务所需的客户端代码的方法。到目前为止,使用基于REST的web服务似乎是一种更特别的方法,即编写接口来匹配可能的调用。手动发起http请求,然后解析响应。这本身就是危险的。
SOAP的美妙之处在于,一旦WSDL被发布,那么业务就可以构造它们的逻辑主干,从而设置契约,对接口的任何更改都会改变WSDL。没有任何回旋的余地。您可以根据该WSDL验证所有请求。然而,由于WSDL没有正确地描述REST服务,因此您没有定义的方式来就通信的接口达成一致。
从商业的角度来看,这似乎让沟通变得容易解释和改变,这似乎是个坏主意。
这个线程中最上面的“答案”似乎说SOAP代表简单面向对象访问协议,然而在wiki中,O意味着对象不是面向对象的。它们是不同的东西。
我知道这篇文章很老了,但我认为我应该用我自己的发现来回应。
REST是一种与SOAP完全不同的范例。关于REST的一篇好文章可以在这里找到:我如何向我的妻子解释REST。
如果你没有时间阅读它,这里是一个简短的版本:REST是一个范式的转变,通过关注“名词”,并限制你可以应用于这些名词的“动词”的数量。唯一允许使用的动词是“get”、“put”、“post”和“delete”。这与SOAP不同,SOAP中许多不同的动词可以应用于许多不同的名词(即许多不同的功能)。
对于REST,四个动词映射到相应的HTTP请求,而名词则由url标识。这使得状态管理比SOAP更加透明,在SOAP中,服务器上的状态和客户端上的状态往往不清楚。
但在实践中,大多数情况下,REST通常只是指以JSON返回结果的简单HTTP请求,而SOAP是一种更复杂的API,通过传递XML进行通信。两者都有各自的优点和缺点,但是根据我的经验,我发现REST通常是更好的选择,因为您很少需要从SOAP获得的全部功能。
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协议也可以很好地工作。