WebService是个很重型的规范，它的应用协议是SOAP（简单对象访问协议），
它所依赖的下层通信方式不单单是HTTP，也有SOAP over SMTP, SOAP over TCP，
由于HTTP协议群众基础广，开发调试方便，所以，成了WebService中最为流行的方式。
SOAP是简单对象访问协议，定义了一种跨平台的分布式系统通信协议。
SOAP需要绑定到更低层次的传输协议（比如， HTTP,RMI,JMS）等。
最常用的是HTTP绑定，所以也经常把SOAP的概念和HTTP混在一起说。
或者可以简单理解为：
SOAP说白了是用http传送xml而已。
SOAP协议 = HTTP协议+ XML数据格式
webservice由于要进行xml解析，速度会有所降低。
现在的开放平台都是用的HTTP接口，不再使用webservice。
曾经不同系统间交互问题时，总是优先考虑webserivce，
现在看到除了一些老牌的公司，比如amazonk对众的接口还是webservice的方式，
其他很多国内新项目的接口都开始转向直接传json的方式。
WebService诞生十几年了，最初是IBM、微软比较热心在推，一直也不温不火。
究其原因，还是WebService实在太笨重了，
SOAP信封犹如婆娘的裹脚布，又臭又长，广大开发人员是叔可忍嫂不能忍，
于是就有了简化版的，叫XML-RPC，再后来，RESTful独领风骚。
在某些业务复杂，稳定性和正确性要求高的领域（如ERP、电商、支付），
WebService还有是用武之地的。
JSON的可读性比XML强几条长安街，解析规则也简单许多。
XML解析的时候规则太多了，动不动就非法字符，动不动就抛异常。
这对追求高开发速度和低开发门槛的企业来说，是个致命伤。
JSON的缺点是数据类型支持较少，且不精确。
比方说：在json里，你无法知道这个价格是int, float还是double。
JSON确实是一种很好的交换数据结构。
除了这个之外，javascript原生支持json解析，且解析起来很简单。这个很重要，
因为http接口大部分是给页面的Javascript解析使用的。
然后为了保持一套接口，app代码也使用这个json接口。所以就流行了起来。
webservice通过xml来传数据的方式导致大量的验证、类型分析、异常处理，性能损耗很大，
并且开发也过于复杂。xml相关的库也很大。
面向一般开发者的API，显然应该考虑简单易用。
而且公开到Web环境中，性能也很重要。
JSON这种适应性超强的格式受欢迎也就很正常了。
XML 是强类型的，在整个解析过程中很多时间都被花在类型检测上了；
JSON 则是弱类型，完全依赖两端代码共同遵守同一界面合约（contract）来保障。
SOAP请求示例
<?xml version="1.0" ?>
<S:Envelope
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:get
xmlns:ns2="http://service.com/">
<arg0>张三</arg0>
</ns2:get>
</S:Body>
</S:Envelope>
SOAP响应示例
<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:getResponse xmlns:ns2="http://service.com/">
<return>你好，张三</return>
</ns2:getResponse>
</S:Body>
</S:Envelope>