REST & SOAP webservice 小结

REST：

　　 REST是一种架构设计，特色是面向资源，存在于互联网的任何事物均可以理解为资源，REST相比较SOAP WS具备比较低的开发门槛。

　　1. 网络上的事物被抽象成资源，每一个资源对应惟一的资源标示（URI）

　　2. 全部对资源的操做都是无状态的

　　REST遵循HTTP规范，其对资源的核心操做对应http method - get/post/put/delete(获取、增长、修改、删除)，经过URI来获取资源并对其进行操做。

SOAP:

　　SOAP有严格的规范和标准，针对安全和事物等的管理更加成熟，同事强调操做方法和对象分离，有WSDL和XSD规范对其定义。对于复杂的业务活动逻辑，

　　将要操做的事物抽象成资源并非一件简单的事，如事务处理，SOAP是更好的选择。

 

SOAP Webservice和RESTful Webservice的比较（转）

成熟度(总的来讲SOAP在成熟度上优于REST)

SOAP虽然发展到如今已经脱离了初衷，可是对于异构环境服务发布和调用，以及厂商的支持都已经达到了较为成熟的状况。不一样平台，开发语言之间经过SOAP来交互的web service都可以较好的互通（在部分复杂和特殊的参数和返回对象解析上，协议没有做很细致的规定，致使仍是须要做部分修正）

REST国外不少大网站都发布了本身的开发API，不少都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用状况要高于SOAP。可是因为REST只是一种基于Http协议实现资源操做的思想，所以各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是由于这种各自实现的状况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。因为这些大网站的SP每每专一于此网站的API开发，所以通用性要求不高。

因为没有相似于SOAP的权威性协议做为规范，REST实现的各类协议仅仅只能算是私有协议，固然须要遵循REST的思想，可是这样细节方面有太多没有约束的地方。REST往后的发展所走向规范也会直接影响到这部分的设计是否可以有很好的生命力。

效率和易用性(REST更胜一筹)

SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各类互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。可是也因为SOAP因为各类需求不断扩充其自己协议的内容，致使在SOAP处理方面的性能有所降低。同时在易用性方面以及学习成本上也有所增长。

REST被人们的重视，其实很大一方面也是由于其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操做抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是可以很好的融合当前Web2.0的不少前端技术来提升开发效率。例如不少大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml做为数据承载，还有（JSON,RSS,ATOM）等形式，这对不少网站前端开发人员来讲就可以很好的mashup各类资源信息。

安全性：

这点其实能够放入到成熟度中，不过在当前的互联网应用和平台开发设计过程当中，安全已经被提到了很高的高度，特别是做为外部接口给第三方调用，安全性可能会高过业务逻辑自己。

SOAP在安全方面是经过使用XML-Security和XML-Signature两个规范组成了WS-Security来实现安全控制的，当前已经获得了各个厂商的支持，.net ，php ，java 都已经对其有了很好的支持（虽然在一些细节上仍是有不兼容的问题，可是互通基本上是能够的）。

REST没有任何规范对于安全方面做说明，同时如今开放REST风格API的网站主要分红两种，一种是自定义了安全信息封装在消息中（其实这和SOAP没有什么区别），另一种就是靠硬件SSL来保障,可是这只可以保证点到点的安全，若是是须要多点传输的话SSL就无能为力了。安全这块其实也是一个很大的问题，今年在BEA峰会上看到有演示采用SAML2实现的网站间SSO，实际上是直接采用了XML-Security和XML-Signature，效率看起来也不是很高。将来REST规范化和通用化过程当中的安全是否也会采用这两种规范，是未知的，可是加入的越多，REST失去它高效性的优点越多。