讨论该问题的原因是之前有一次开会，讨论到webservice的实施，我直接给出的结论是应该使用rest替换掉原来的soap接口，原因是soap"太重量级了"(其实我内心想的是rest的实现比soap简单)但是当被问到怎么"重量级"的时候又是说不出来的。因为这个词'也是之前随便搜搜得到的答案。因为好像很多人就是这么阐述他们的去别的。所以究竟他们有什么不同呢，我简单说一下我的理解。
1. 从定义上他们就是完全不同的，soap是一个协议，restful是一种架构风格，是直接基于http协议实现的。所以直接可以看出当你想实现webservice的时候，后者的实现是相对简单的。soap相当于将要传输的内容又包了一层，都封装在envelope里面进行传输，而restful可以理解为发送的就是请求本身，是透明的。
2. 安全校验: 通常的做法是当有从客户端 Client2 发出的 HTTP 请求都经过代理服务器 (Proxy Server)。代理服务器制定安全策略：所有经过该代理的访问 User 和 User List 资源的请求只具有读取权限，即：允许 GET/HEAD 操作，而像具有写权限的 PUT/DELTE 是不被允许的。那么如果是使用soap，那么代理是没有办法确定它的请求类型的，因为之前讲到的，soap的请求是被封装过的，很难解析envelope里面的请求类型。
3. 关于缓存，REST 的应用可以充分地挖掘 HTTP 协议对缓存支持的能力。当客户端第一次发送 HTTP GET 请求给服务器获得内容后，该内容可能被缓存服务器 (Cache Server) 缓存。当下一次客户端请求同样的资源时，缓存可以直接给出响应，而不需要请求远程的服务器获得。而这一切对客户端来说都是透明的。而soap还是我们提到的那个问题，无法知道请求类型。(默认soap使用的是post)。这一点在我们新要使用的webservice上极为重要，因为我们只提供一个get接口供用户得到信息，且信息内容不会经常改变。而且更重要的事get比post要快。
参考文章:
http://www.importnew.com/24695.html
https://blog.csdn.net/wdeng2011/article/details/78274683
https://blog.csdn.net/yanbober/article/details/45308935
https://blog.csdn.net/zzk220106/article/details/78595108/(get vs post)
