为什么很多第三方接口，都改成了基于http，直接传递json数据的方式来代替webservice?-tutoriel php-php.cn

为什么很多第三方接口，都改成了基于http，直接传递json数据的方式来代替webservice?

WBOY

Libérer： 2016-06-06 20:43:36

original

1534 Les gens l'ont consulté

曾经不同系统间交互问题时，总是优先考虑webserivce，现在看到除了一些老牌的公司，比如amazonk对众的接口还是webservice的方式，其他很多国内新项目的接口都开始转向直接传json的方式。我知道的优势之一，就是webservice的消息体肯定比json这种方式要大。请问，除此之外，设计这些对众接口的时候，还有什么其他的考虑吗？

回复内容：

你这实际上是三个问题，从WebService到今天流行的RESTful API(JSON) over HTTP，经历了数次变革

1 WebService有很多协议，为什么HTTP比较流行？

WebService是个很重型的规范，它的应用协议是SOAP（简单对象访问协议），它所依赖的下层通信方式不单单是HTTP，也有SOAP over SMTP, SOAP over TCP，由于HTTP协议群众基础广，开发调试方便，所以，成了WebService中最为流行的方式。

甚至很多公司在内网通信，也用HTTP来做，比如，应用调用搜索引擎，Solr就是一个例子。

但HTTP也是TCP上性能比较差的协议，因为HTTP是基于TCP的，有3次握手，再加上HTTP是个文本传输协议（虽然也可以传二进制的附件，但业务逻辑还是文本用的多），又有很多复杂的HEADER。所以人们发明了一些更高效的通信协议来做远程调用，比如ACE、ICE、Corba、淘宝的HSF，但这是后话了，不展开细说。你只要知道，HTTP之所以流行，乃是简单易用群众基础广的结果。

2 WebService为什么不如RESTful API流行

WebService诞生十几年了，最初是IBM、微软比较热心在推，一直也不温不火。倒是XML-RPC, RESTful以及比RESTful还要简陋的远程调用方式后来居上。感觉是不是有点像民间的Spring干掉官方的EJB？

究其原因，还是WebService实在太笨重了，SOAP信封犹如婆娘的裹脚布，又臭又长，广大开发人员是叔可忍嫂不能忍，于是就有了简化版的，叫XML-RPC，后来伴随着Web2.0流行，RESTful独领风骚。我在10年前做过一个产品，纯PHP+JS，标准的WebService，连WSDL我都要专门写个PHP程序来生成，还好只是我一个人开发，要是团队协作，我早就被骂得不成人形了。

再后来，连RESTful都被嫌弃了，大伙儿干脆连PUT、DELETE都懒得用，直接用GET和POST。

同时，我得说，这只是在互联网领域，大部分企业的业务逻辑相对简单，同时工期又变态的短（就像大部分互联网创业公司用糙快猛的PHP，而不用相对严谨的Java一样）。在某些业务复杂，稳定性和正确性要求高的领域（如ERP、电商、支付），WebService还有是用武之地的。

3 为什么JSON比XML流行

还是易用性，JSON的可读性比XML强几条长安街，解析规则也简单许多。XML解析的时候规则太多了，动不动就非法字符，动不动就抛异常。这对追求高开发速度和低开发门槛的企业来说，是个致命伤。

JSON的缺点是数据类型支持较少，且不精确。比方说：

<code>price:12580
</code>

Copier après la connexion

在json里，你无法知道这个价格是int, float还是double。

所以，如上面第二条所述，在一些业务要求较高的领域，还是XML更合适。

最后说一下性能，JSON的性能高于XML，除此之外，基于XML和HTTP的WebService, 基于JSON的RESTful API，并没有性能差异。

XML性能糟糕到什么地步呢，有一种专门的CPU叫做XML Accelerator，专门为XML解析提供硬件加速。

JSON确实是一种很好的交换数据结构。
除了这个之外，javascript原生支持json解析，且解析起来很简单。这个很重要，因为http接口大部分是给页面的Javascript解析使用的。然后为了保持一套接口，app代码也使用这个json接口。所以就流行了起来。

json解析比较简单，在js或者php很容易就可以解析成对象，易于操作

用过Web Service，感觉：
过于复杂庞大，通过xml来传数据的方式导致大量的验证、类型分析、异常处理，性能损耗很大，并且开发也过于复杂。xml相关的库也很大，部署成问题。
而其提供的所谓“自动发现”也由于复杂等等原因很难使用；安全性也非常复杂，各种语言、框架的实现想要兼容
也要费一番力气。

面向一般开发者的API，显然应该考虑简单易用。而且公开到Web环境中，性能也很重要。JSON这种适应性超强的格式受欢迎也就很正常了。

编程语言对json的自然支持也是一个原因。比如json字符串可以自然的变成javascript对象操作，反过来也一样。

REST就是答案

我也热爱json，所以也整了一个工具站http://www.sojson.com

个人经验来说吧，WebService 很复杂，调用庞大，哪怕像是 .net 这种原生提供相关支持库的工具用起来也多少力不从心，而且 XML 人手阅读哪怕有语法高亮也是吃力，姑不论效率问题了。

JSON 相比之下轻量得多，可谓简陋，但容易阅读许多原生不支持 WebService 的语言和工具都提供了 JSON 支持。简单的语法也带来了更好的效率。

前面有人提到类型系统的问题。XML 是强类型的，在整个解析过程中很多时间都被花在类型检测上了；JSON 则是弱类型，完全依赖两端代码共同遵守同一界面合约（contract）来保障。前者适合于存在按类型检索重载的场合，一般适用于 CXX、C#、Java 这类强类型的语言；而后者则更适用于 Javascript、Python、Objective-C 这类弱类型语言。

不过 JSON 也并非不可指定类型。通过合理的上层协议便可实现，再不需要与 Javascript 直通的时候也可以对语法小修改来实现。举例：

<code>MTSession {
    id: MongoIdentifier {
        id: "1225…"
    },
    uid: 2024,
    flags: /* Dictionary */ {
        authSaved: true,
    }
}
</code>

Copier après la connexion

異質系統的通訊中只關心兩個問題

物件模型以及資料

Web Service使用的SOAP可以自描述物件模型
可是使用xml來傳遞資料實在是耗費太多資源了

這個時候，JSON的輕量優點就突顯出來
至於物件模型
你都要用我的服務，看一下文件不過份吧

我觉得两个原因，rest最开始是为页面服务的。js原生支持json，同时json是kv型数据，用nosql更好

webservice?没听说过
我就知道json

实在是大赞