Flex与JSON及XML的互操作
平台需要互操作性。在这篇文章中,作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容,还演示了如何使用as3core库来解码JSON消息。
作者 Mark Little译者 黄璜 发布于 2008年11月3日 上午1时49分
在回应How to GET a Cup of Coffee这篇文章时,Bill Burke,RESTeasy(一个JAX-RS实现)的主要开发者之一,这样谈到:
我始终没能被Atom的价值触动,在这个特例里,它又比”multipart/*”之类的好在哪里呢?为了支持Atom XML交互格式,你又不得不增加客户端及服务器端的复杂性。通过multipart,我们可以以一种更加紧凑的格式来获取同样的信息(通过位置[Location],内容位置[Content-Location],和内容类型[Content-Type]报头)。
就算比multipart更好,为什么不就返回一个逗号分隔的有序URI列表呢?
REST吸引我的地方之一(但不仅如此)就是你可以关注于你的服务之间交换的数据格式而不是用某种中间协议来在交互中充当隧道。目前来说,Atom于我而言不过是SOAP的另一种更具诱惑性的替代罢了。
Bill de hOra试图帮助(另一个)Bill来回答这一问题,并为他列出了Atom的七大要领:
根据Bill(de hOra)的说法,SOAP以前(或是现在?)的问题(就一个问题?)在于“最小化的信封什么也没定义,扩展规则采用了错误的默认规则[mustUnderstand],而内容编码成为了遗留的功课。 ”
他接着总结到这些原则实际上比Atom本身更为广泛适用:
就算你不喜欢Atom(或就此不喜欢XML),如果你的传送格式想要在Web上生存下去的话,你也必须处理这七项基本类型。这就是我对那些喜欢更直接一点并具体到域,而不是将整个域映射到像Atom和SOAP这种抽象格式上的人们想说的话——就格式来讲,对此展开进攻你大概就能获得80%的质量和健壮性了。我相信它对任意Web或去中心化系统上所用的格式都是适用的,而不限于XML。一旦一种稀松的数据格式被放任自流,你不能仅仅去重构调用者了,你只有不断的版本控制,版本控制,版本控制。
实际上一篇最早期的Atom文章提到如下几点:……
……Atom API设计在思想上与如下几点指导原则保持了高度一致:
- 定义良好的数据模型——包括模式及其它一切!
- 文档风格的Web服务,而不是RPC
- 发挥XML和名字空间的所有优势
- 发挥HTTP的所有优势
- 安全,因此在明文中没有密码
这确实与SOAP的开端截然不同,随着越来越多的人 开始出于各种理由拥抱Atom,有理由相信此刻它是REST最受宠的一个孩子。
查看英文原文:The Value Of Atom?
谢谢 受益匪浅
开发者资讯 | 我们致力于为开发者提供动力!
欢迎你的到来!
jacken.com.cn
嘻嘻
平台需要互操作性。在这篇文章中,作者仔细研究了Flex和JSON及XML的互操作性。文章也包含了使用E4X库来将XML映射到图表和表格组件的内容,还演示了如何使用as3core库来解码JSON消息。
本文将简要介绍面向组合编程(COP,Composite Oriented Programming)的概念,展示它如何规避OOP存在的一些问题,并重新点燃使用可重用部件组装领域模型(Domain Model)的希望。
Mike Snell和Lars Powers用他们最近由Sams出版的新书《Visual Studio 2008揭秘》,试图帮助大家提高开发人员的生产力。本文包括一个下载样章——第10章调试。
Pierre Vigneras在本文中讨论了作为标准之一的BPEL所存在的问题。Pierre先给我们大致介绍了一个简单的并行流程,接着讨论了从业者在试图以一个结构化模型为基础表达非结构化流程时遇到的一系列问题。
Jeff Dwyer就关于他的新书(《Pro Web 2.0 Application Development with GWT》)、GWT1.5以及创建可搜索的Ajax应用谈了一些他的见解。
我们需要设身处地地为客户及客户的业务本身着想,与客户同舟共济。更多创新的思路、产品和模式也同样将为IT业带来新的出路。IT业并不需要坐以待毙,在春天到来之后,市场将会更加繁荣!
1 条回复
回复