关于SOAP和REST的一些疑惑
在网上找了很多文章,没能解开我心中的疑惑。
我的问题是,为啥拿SOAP和REST对等地来比较?如果我没理解错的话,SOAP是一个协议标准。而REST是一种架构风格。严格意义上SOAP和REST是不对等的。但是网上居然有人把REST和SOAP分别理解为Web Service的两种实现方式。所以我又凌乱了。到底是我理解错了还是网上的那些人理解错了呢?
而且,在我看来,在一定情况下,SOAP和REST甚至可以兼容不是么?SOAP定义的是交换数据的一些规范和标准(以XML为数据格式),而REST则更多的是对资源的表现形式和操作地简化和规范。所以SOAP两者并不互斥呀,为什么要拿SOAP和REST来比较?意义又何在呢?(以上纯属个人观点,如果本人理解有误请指出,谢谢^_^)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如您所说,RESTful是一种stype,SOAP是一种protocol。摘自wikipedia REST字段
下面这个问题提的很棒,我想利用回答这个问题来顺道解释1)为什么REST和SOAP会被摆在一起讨论,2)SOAP和REST如何兼容
造成SOAP和REST放在一起讨论是因为,网络上很多工程师把REST风格和REST的实现混淆了。REST的概念比较宽泛,本身如果符合1)Client–server, 2)Stateless, 3)Cacheable, 4)Layered system, 和5)Uniform interface这几个主要的限制,就是RESTful的设计。同时呢,由于HTTP是一个很容易满足stateless, cacheable,uniform interface的protocol,所以实际上REST被默认就是用HTTP来实现,很多人耳熟能详HTTP的verb如何对应到resource的CRUD,仿佛也成了REST风格本身的死规定。我认为其实不然,以HTTP中的PUT为例,如果用PUT来实现resource的update,那么就必须要保证idempotent,每次传给server的信息,必须是resource的全部信息,不能作partial update。不难发现,用PUT来实现update,其实是在REST的constraint上又加上了HTTP的一些限制。如果我们放弃PUT的constraint,采用POST来实现update,则partial update是可以的。紧接着就由一个问题,既然PUT被POST替代,那么我们是否可以用POST来代替GET和DELETE呢?笔者认为应该没问题,一个很现实的例子,如果browser不支持DELETE,用POST来work around是很常见的。而且用REST的作者的一段话来印证
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
okay, 再来看看SOAP,很多在HTTP上实现的SOAP协议就是用POST来实现的 (wikipedia里SOAP的一个sample http://en.wikipedia.org/wiki/SOAP#Example_message)
因此,当我们使用HTTP POST来实现REST,再加上XML的数据传输格式,其实我们就是在SOAP上面实现了RESTFul的"风格"(尽管还网上没人提到RESTful SOAP,但我觉得这在理论上是没问题的)。
与RESTful SOAP相对的一个例子,很多基于Rails的website(并非说Rails不好,Rails大行其道使得REST风行,故举例)URL风格是/callSomeMethodWithArgumentA, /callSomeMethodWithArgumentB,非常长,不uniform,不满足REST的限制,这些route都是不RESTFul的,我们可以称之为non-RESTful HTTP
长话短说,本人认为SOAP协议和REST架构风格是兼容的。虽然,约定俗成,REST的具体实现一般采用HTTP,且充分利用HTTP verb的不同特性,从而形成了一些约定俗称的范式,但这种实现本身不是REST"风格"的核心。