曾经不同系统间交互问题时,总是优先考虑webserivce,现在看到除了一些老牌的公司,比如amazonk对众的接口还是webservice的方式,其他很多国内新项目的接口都开始转向直接传json的方式。我知道的优势之一,就是webservice的消息体肯定比json这种方式要大。请问,除此之外,设计这些对众接口的时候,还有什么其他的考虑吗?
Copyright 2014-2026 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
json解析比较简单,在js或者php很容易就可以解析成对象,易于操作
用过Web Service,感觉:
过于复杂庞大,通过xml来传数据的方式导致大量的验证、类型分析、异常处理,性能损耗很大,并且开发也过于复杂。xml相关的库也很大,部署成问题。
而其提供的所谓“自动发现”也由于复杂等等原因很难使用;安全性也非常复杂,各种语言、框架的实现想要兼容
也要费一番力气。
面向一般开发者的API,显然应该考虑简单易用。而且公开到Web环境中,性能也很重要。JSON这种适应性超强的格式受欢迎也就很正常了。
编程语言对json的自然支持也是一个原因。比如json字符串可以自然的变成
javascript对象操作,反过来也一样。REST就是答案
个人经验来说吧,WebService 很复杂,调用庞大,哪怕像是 .net 这种原生提供相关支持库的工具用起来也多少力不从心,而且 XML 人手阅读哪怕有语法高亮也是吃力,姑不论效率问题了。
JSON 相比之下轻量得多,可谓简陋,但容易阅读许多原生不支持 WebService 的语言和工具都提供了 JSON 支持。简单的语法也带来了更好的效率。
前面有人提到类型系统的问题。XML 是强类型的,在整个解析过程中很多时间都被花在类型检测上了;JSON 则是弱类型,完全依赖两端代码共同遵守同一界面合约(contract)来保障。前者适合于存在按类型检索重载的场合,一般适用于 CXX、C#、Java 这类强类型的语言;而后者则更适用于 Javascript、Python、Objective-C 这类弱类型语言。
不过 JSON 也并非不可指定类型。通过合理的上层协议便可实现,再不需要与 Javascript 直通的时候也可以对语法小修改来实现。举例:
異質系統的通訊中只關心兩個問題
物件模型以及資料
Web Service使用的SOAP可以自描述物件模型
可是使用xml來傳遞資料實在是耗費太多資源了
這個時候,JSON的輕量優點就突顯出來
至於物件模型
你都要用我的服務,看一下文件不過份吧
我觉得两个原因,rest最开始是为页面服务的。js原生支持json,同时json是kv型数据,用nosql更好
webservice?没听说过
我就知道json
实在是大赞