架构师2015年第2期


卷首语 卷首语 又到年根,作为一位技术媒体人开始频繁拜访各家公司,总结过去, 面向未来,在这里把发现的一些新趋势和自己的感受梳理一下,就不 透露公司名称了,供大家参考。 公有云的第三方评测将越来越受到重视,我指的并不是知名国际咨询 公司提供的研究报告,而是来自于社区圈搞的评测结果。现在信息透 明度很高,开源的测试工具也多,从磁盘 IO 到线程锁再到数据库性能, 有社区大神开始评测国内主流的云厂商。这些实实在在的数据结果更 接“地气”,对于正在对云服务做技术选型的开发者和公司来说,具有较 高的参考价值。对于有些云厂商来说,可能面子有些挂不住,不过令 人欣喜的是,更多的云厂商持有开放的心态,不忌惮结果,勇于面对, 不断改进。 托管云、私有云、混合云将在 2015 年成为云厂商的重点方向。长期以 来,公有云的市场营销和品牌战略让国内社区的注意力都放在了公有 云上,不过这只是云计算市场的一块,增长很快,但体量不大。从国 内现状来看,多数大中型企业因为信息安全、IT 设施复杂性、系统稳 定性等原因,短期内不会上线公有云,所以其他类型的云有了发展机 会,而且这块市场的体量很大。据我所知,目前几家主流云厂商包括 内资和外企都提供非公有云的服务形式,并且也是他们在未来一年关 注的重点。所谓“公有云赔本赚吆喝,私有云闷声发大财”的说法有一定 的道理。 外资云是困难和机遇并存。困难的是,公有云项目迟迟难以落地,目 前只有一家真正落地,其他项目还在评估和运作中,眼看国内的云计 算市场发展的如火如荼,外资云有自己的技术和品牌优势,也是着急 啊。目前外资云能做的一方面是积极寻求落地,另外一方面是积极发 展非公有云服务,本来这几家外资云在这方面就有比较完备的解决方 案,最近在通过一系列活动发出自己的声音。 研究性组织越来越重视业务价值。曾几何时,贝尔实验室的辉煌成就 了无数个科学家和革命性技术,但对于 AT&T 来说,其产生的企业价 值对不起投入。就是几年前,很多 IT 巨头还在强调各种研究院的学术 独立性,但是现在的产业转型期中,企业更加现实,科研成果在一段 卷首语 时间内必须要有看得见的经济效益,鼓励研究人员走出去,面向客户, 解决实际问题。对于科学家来说,不知道是好事还是坏事。 O2O 的布局越来越重要,从我走访的几家垂直领域互联网公司来看, 即使在线上包括移动端走的很好,也都在布局 O2O,打通线上线下的 渠道链,形成比较完整的生态圈,并且能够成为规则的制定者,而不 仅仅是参与者,目前面临的挑战包括支付形式的多样性、线下产品的 运营等等。 大数据分析逐渐成为企业分析用户行为习惯并提出优化策略的重要手 段,搭建和运营大数据分析的平台也成为很多企业的痛点,而第三方 的数据分析平台又存在不可靠或者站错队的问题,不敢轻易使用,所 以预计大数据这块的人才需要未来将比较旺盛。 云服务的差异化竞争将更加明显,我走访了几家云厂商,发现每家的 定位都比较清晰,有的强调市场和运营优势,有的强调技术优势,有 的关注普通消费者和个人站长,有的关注中型企业,由于公有云服务 的投入成本比较高,BAT 几家财大气粗,其他国内云厂商都在寻找自 己的定位,提供差异化的创新服务。 在 2015 年,整个国内的 IT 产业将有更多看点,而 InfoQ 也会从多个角 度、通过多种形式进行全面而深入的报道,和大家一起成长。 ——InfoQ 中国总编辑 崔康 敏捷 Agile DevOps Big Data 大数据 创业 移动 云 运维 前端 金融 安全 微服务 文化 Mobile Culture Frontend Security Startup Architecture Finance Microservice Cloud 架构 可扩展、高可用架构设计 新兴大数据处理技术与工具 自动化运维 云计算平台构建与应用 团队建设 软件质量 敏捷之后,是什么 知名移动案例分析 挑战全栈开发 抢票热线:010-64738142 会务咨询:qcon@cn.infoq.com 精彩内容策划中,讲师自荐/推荐,线索提供:speakers@cn.infoq.com 更多经典专题 精彩内容 敬请登录:www.qconbeijing.com 移动开发最佳实践 安全、隐私与风控 互联网金融背后的技术架构 微服务和响应式框架 Java和新锐语言 超越JavaScript 思考开源 基于大数据的机器学习和数据挖掘 技术创业 针对软件开发领域的热点与趋势,议定18个最具实践价 值的专题,覆盖更广的开发者人群,为参会者提供更多选择 目录 目 录 解读 2014 | Review 解读 2014 之 Android 篇:连接世界 专题 | Topic Web API 设计方法论 亿级用户下的新浪微博平台架构 Netty 系列之 Netty 百万级推送服务设计要点 Java 多线程编程模式实战指南:Immutable Object 模式 观点 | Opinion 技术团队的情绪与效率 慎用 Java 日期格式化 Node.js 和 io.js 性能差异巨大 推荐文章 | Article 新 JavaScript 库的激动人心之处 高效运维最佳实践(01):七字诀,不再憋屈的运维 解读 2014 | Review 解读 2014 之 Android 篇:连接世界 作者 郭亮 【编者按】 2014 年,整个 IT 领域发生了许多深刻而又复杂的变化, InfoQ 策划了“解读 2014”年终技术盘点系列文章,希望能够给读者清晰 地梳理出技术领域在这一年的发展变化,回顾过去,继续前行。 本文为“解读 2014 之 Android 篇”,Android 从 2008 年发布,到 2014 年 末已经 6 岁。经历了前几年的高速发展,Android 已经当之无愧的成为 全球用户最多的手机操作系统。2014 年虽然不是 Android 发展最快的 一年,却是变化最快、扩张最大的一年。最新版本的 Android 5.0 Lolipop 无论是用户体验还是系统性能都有着颠覆性的改变与提升。 Material Design 的出现,更使 Android 设备在体验方面第一次和 iOS 站在了同 一个高度。经历了一年多的开发与测试,谷歌也发布了第一款官方正 版 IDE——Android Studio,功能强大堪比开发神器。Android Wear、 Android TV、Android Auto 已经领先一步进入市场,越来越多的智能硬 件都采用 Android 系统,希望借助 Android 生态环境来构建属于自己的 市场。谷歌对于国内开发者也变的更加友好,全球最大的 Android 市 场 Google Play 已经支持中国的开发者上传 App。本文作为 Android 这 一年的总结,从系统本身、开发工具、硬件配置、国内外生态环境四 方面介绍了 Android 这一年的发展与改变,并且结合当前市场大胆展望 了 2015 年 Android 的发展方向。 系统 谷歌在 2014 年的 I/O 大会上发布了最新的操作系统 Android Lollipop, 也就是 Android 5.0。Android Lollipop 是有史以来 Android 最大的一次 改变。首先,在感官界面设计上,Android Lollipop 不仅使用了新的配 色,同时使用了非常时尚的扁平设计,彻底迎来了 Android 系统的扁平 化时代。此外,系统的多任务功能进行了一次基础性的重大调整。 Android L 中用户将会拥有一个基于卡片的清单,其中呈现的并不是应 用,而是任务。新的任务机制,能够节约大量的系统性能。另外全新 的通知中心也不再乏味,当然还有大量的其它新特性,相信第三方系 统插件的市场将会越来越小。 解读 2014 | Review 系统方面重重之重的改变应该是 Material Design。谷歌将 Material Design 定义为一种设计语言,其特点是能在将整个素材铺平的同时还 遵循一定的物理材质的需求。Material Design 的设计风格可以让应用感 觉更活泼、具有更丰富的颜色,以及动画效果更真实等等。从技术角 度分析,Material Design 完美解决了两个非常大的需求,其一是阴影, 它所有的阴影都是默认系统实现的,开发者无需去自定义。另一个是 动画,可以说 Android 5.0 将动画应用到了各个角落,动画效果甚至要 超过 iOS,并且其效果不是简单的贴图,更像是真实的投影。谷歌自家 的应用都已经使用了 Material Design,对于开发商来说,越早使用 Material Design,不仅有机会得到 Google Play 或国内市场的设计推荐, 更有可能提升 App 的留存率。 Android 5.0 对于硬件的兼容性比之前的版本有了重大提升,原生系统 就支持多种设备,同时支持手机、Android Wear、Android TV、Android Auto,并且谷歌发布了这些设备的 SDK ,Google Play 已经可以上传 Wear App 和 TV App。基于 Android 5.0 的整个生态链已经全部打通。 工具 一年前 Google 发布 Android Studio 测试版的时候,笔者天真的以为再 有三个月就会出正式版,这一等就是一年多的时间。但这种等待是值 得的,单从美观上评价,自带的 Darcula 主题炫酷黑界面实在是高大上, 极客范,相比而言 Eclipse 的黑色主题太 low 了。Android Studio 亮相之 初就支持 Gradle,Gradle 集合了 Ant 和 Maven 的优点,不管是配置、 编译、打包都非常棒。Android Studio 的编辑器非常的智能,除了吸收 Eclipse+ADT 的优点之外,还自带了多设备的实时预览,这对 Android 开发者来说简直是神器。提示补全对于开发来说意义重大, Studio 则 更加智能,智能保存,从此再也不用每次都 Ctrl + S 了。熟悉 Studio 以后效率会大大提升。 Android 碎片化是让开发者非常痛苦的一件事情,一个 UI 需要去反复 测试多个设备,Android Stuido 解决了开发者的这个痛点,它支持多款 设备的实时预览。Android Studio 还提供更多的特性比如内置终端、完 善的插件机制,还可以安装 Markdown,你想要什么插件,直接搜索下 载。 Android Studio 自带版本控制系统如 GitHub、Git、SVN 等,可以 直接 check out 你的项目。 解读 2014 | Review 硬件 在美国智能手机市场上,苹果可能是当之无愧的“王者”,但在全球范围 内,三星的至尊地位则是无可置疑的。Android 设备包括高、中、低端 产品,价格从几百元到五、六千元不等。从市场份额上看要高于 iPhone 系列。而国内市场用户最多的应该是小米,小米凭借 MIUI 成为了世界 上最大的第三方 ROM 产商,迅速进入市值 100 亿美金公司队列。2014 年谷歌、三星、HTC、小米、魅族等等都发布了多款手机,这些手机 的形态、尺寸、性能规格各异,大部分手机还无法升级到 Android 5.0 系统, Android 2.3 依然不死,Android 的碎片化程度越来越高。对于 开发者来说应用的开发更加困难了。不过我们不再有理由去抱怨,因 为 iOS 的多屏幕适配繁琐性不低于 Android。 2014 年三月谷歌正式发布了针对智能手机和其它可穿戴设备的全新平 台——Android Wear。Android Wear 除了最基本的查看手机通知消息, 以及记录用户运动情况以外,还可以通过 Google Play 市场下载应用实 现很多用户意想不到的功能。Android Wear 的发布催生了一大批 Android Wear 设备的诞生,年末苹果发布了自己的智能手表,微软同 样推出了自己的智能手环。虽然 Android Wear 抢先一步进入市场,但 却没有激起太大的浪花。与苹果发布的 Apple Watch 相比,Android Wear 无论从外观上还是从软件功能上都要逊色很多。笔者认为未来还会是 苹果引领智能手表市场。但 Android Wear 的表现并不影响 Android 进 入客厅的步伐,乐视 TV、小米电视、天猫盒子已经展开了激烈的竞争, 搭载 Android L 系统的 TV 将会是市场的主力军,传统电视厂商都已经 开始研发自己的智能 TV,笔者想说的是 Apple TV 竞争非常激烈。 2014 年的硬件产品不全是美好,还充满了各种遗憾。小米没有推出更 具吸引力的产品、魅族预售后 2 个多月都拿不到真机、智能汽车还不 是真的智能…但对笔者来说,最大的遗憾应该是 Google Glass 消失了。 2013 年 Google Glass 被称为是最伟大的发明与改变,那时我们都感觉 世界如此之小,每一位极客都希望能体验带着 Google Glass 去环游世 界。但 2014 年,Google Glass 没有新的进展,I/O 大会只字未提。有可 能是因为体验的问题,有可能是因为材料问题,有可能是用户失去了 耐心,Google Glass 发展令人担忧。 生态 谷歌在 I/O 大会推出了最新移动操作系统、设计语言,并正式启动 Android“连接世界”战略,将 Android 带入汽车、客厅、可穿戴设备、 健康管理等更广阔的领域,谷歌利用自己的开放优势,借助三星、华 解读 2014 | Review 为等第三方厂商正打算抢先在所有智能设备终端上布局。任何的设备, 甚至灯泡都可以烧录 Android 系统,每个公司甚至个人都可以利用 Android 系统定制自己的智能硬件,然后利用已经成熟的应用生态圈去 带动产品发展。对于 Android 来讲,这样的好处是发展迅速,但不足是 产品质量很难保证,碎片化严重。而苹果是软硬件追求极致的公司, 无论是 iPhone、Mac 还是 2015 即将上市的 Apple Watch 都堪称极客产 品。谷歌显然也意识到了这个问题,从去年谷歌的一系列举措,我们 可以发现谷歌将加大对于 Android 的控制,软件层面将会出现更多的谷 歌原生应用,而硬件方向,谷歌将会挑选一些大的厂商合作推出相关 产品,比如有消息称谷歌将会与国内电视厂商合作在春节时推出 Android TV。 谷歌正在大步前进,连接整个世界,小米搭着 Android 的肩膀,已经成 为了巨人,微信已经成为世界上最大的 IM,老罗也火了一把。前两年 有人说,很少有 CP 从 Android 身上赚到钱,只愿意开发 iOS App。2014 Google I/O 大会上谷歌公布了一组数据,原话是这样的“In fact, since last year’s I/O, we have paid out over $5 billion to developers on top of Google Play”,比 2013 年的 20 亿美金翻了 2.5 倍,这还仅仅是 Google Play 一 个市场,从而可见 Android 市场潜力有多大。国内有大量的公司依靠 Android 不仅赚到了钱,而且抢到了市场份额,比如像各种 App 发分市 场。Google Play 已于 2014 年支持中国开发者,国内的开发者终于不用 冒着被封号的风险去使用淘宝上购买来的 Google Play 账号。但反观国 内市场,整个移动领域的盈利模式还令人担忧,很多开发商还停留在 刷数据、冲 KPI 阶段,移动广告公司扣量严重、积分墙无法通过市场 等。如果无法赚到钱,投资人还会有多少耐心? 市场前景一片好,但小的团队、个人开发者的发展却变的更加的艰难。 移动领域已经度过了发展最快的几年,市场需要求已经基本饱和,越 来越多的资源向大的 CP 靠拢。两年前一个技术、一个产品经理开发一 款 App,迅速拥有 20 万用户的现象已经很难出现。很多渠道都需要 Money,App 市场也开始搞竞价排名,更是使新入市、低实力的开发者 毫无竞争力。市场刷榜从 iOS 感染到了 Android,打包党变的更加猖狂, 目前市场上有将近 70%的 App 都被二次打包,笔者身边有一位朋友, 辛辛苦苦开发几个月的 App,上架才一周就被打包,并且自己的 App 说是盗版被下架,而真正的盗版却成了正版。国家对 Android App、分 发市场的监管力度目前还比较小,有好处但坏处也不小。 国内外关于 Android 的技术环境还是相对薄弱,这与 Android 开发门槛 低有很大的关系,国内的开发者社区活跃度比较低,优秀的技术分享 更是非常稀缺。iOS 的技术氛围明显要强与 Android,iOS 有 objc.io 这 解读 2014 | Review 样世界一流的开发社区,很多优秀的技术博客产出了大量的高质量文 章。如果有能力,组织一个高、精、尖的社区应该有很大的发展潜力。 2015 由于 Android 天生安全性没有 iOS 高,随着手机变成银行卡、支付宝的 钥匙,移动安全将更加重要。移动安全一方面是基于手机用户,另一 方面是保证大量 CP 的正版利益。开发一款 App 的成本越来越低,国内 早已经出现类似于一键建站的站长工具,所以对开发者的要求更加严 格。目前入驻移动领域的厂商数不胜数,面向 CP、面向企业级的服务 将会很受欢迎,2015 年一定会出现更多类似于 Umeng 分享、ShareSDK、 可集成 IM 这种第三方服务产品,这个市场竞争还不太激烈,可做的模 块很多。Android App 将会向模块集成方向发展。 苹果的 CloudKit 提供了完善且有弹性的后端解决方案,其目的是帮助 开发者减轻编写服务器代码和维护服务器的需求,从而降低开发 iOS 应用的成本,有助于维护 iOS 生态圈的繁荣。谷歌 2014 年 10 份收购了 Firebase,Firebase 与 CloudKit 属于同一款产品——BaaS(后端即服务: Backend as a Service)。BaaS 因是移动互联网才诞生出来的工具。如今 O2O 发展的势头猛烈,很多传统行业本身的核心竞争力不在技术或者 app 层面,移动应用只是为了承载核心服务。所以能够以一种简单的方 式搭建一个可用的 App、轻应用、HTML5 页面是最好的选择,就像我 们不需要自己去搭建一个推送服务器,不需要自己去做数据统计、数 据分析一样。2015 年,更多的 BaaS 产品将会出现,移动产品中的的数 据存储、文件管理、消息推送等服务将会直接由 BaaS 产品提供,大量 移动开发者不再需要去搭建服务器,开发成本将大大降低。相信 APICloud、bmob 之类的平台会迅速成长起来,将提供更强大的功能。 当然,BAT 也可能提供自己的 BaaS 产品,微信或许会为是降低开发门 槛提供类似 Parse 的服务,阿里借助 BaaS 产品给开发者提供新的变现 方式也是很有可能的。 谷歌会将更多的资源开放给中国市场,并且会和国内的厂商合作,加 强对 Android 的控制。无论是因为国内的市场透明度不好,还是因为国 内市场已无发展潜力,都是时候开发国际版 App 了。猎豹就是典型的 例子,凭借大量海外高质量用户成功上市。 基于 Android 生态的智能硬件、软硬结合产品越来越多,但暂时不会颠 覆行业,进入普通消费者的生活还需要市场培养。 专题 | Topic Web API 设计方法论 作者 Mike Amundsen,译者 吴海星 为 Web 设计、实现和维护 API 不仅仅是一项挑战;对很多公司来说, 这是一项势在必行的任务。本系列 将带领读者走过一段旅程,从为 API 确定业务用例到设计方法论,解决实现难题,并从长远的角度看待在 Web 上维护公共 API。沿途将会有对有影响力的人物的访谈,甚至还 有 API 及相关主题的推荐阅读清单。 这篇 InfoQ 文章是 Web API 从开始到结束系列文章中的一篇。你可以 在这里进行订阅,以便能在有新文章发布时收到通知。 设计 Web API 不止是 URL、HTTP 状态码、头信息和有效负载。设计 的过程——基本上是为了 API 的“观察和感受”——这非常重要,并 且值得你付出努力。本文简要概括了一种同时发挥 HTTP 和 Web 两者 优势的 API 设计方法论。并且它不仅对 HTTP 有效。如果有时你还需 要通过 WebSockets、XMPP、MQTT 等实现同样的服务,大部分 API 设计的结果同样可用。可以让未来支持多种协议更容易实现和维护。 优秀的设计超越了URL、状态码、头信息和有效负载 一般来说, Web API 设计指南的重点是通用的功能特性,比如 URL 设计,正确使用状态码、方法、头信息之类的 HTTP 功能特性,以及 持有序列化的对象或对象图的有效负载设计。这些都是重要的实现细 节,但不太算得上 API 设计。并且正是 API 的设计--服务的基本功能特 性的表达和描述方式--为 Web API 的成功和可用性做出了重要贡献。 一个优秀的设计过程或方法论定义了一组一致的、可重复的步骤集, 可以在将一个服务器端服务组件输出为一个可访问的、有用的 Web API 时使用。那就是说,一个清晰的方法论可以由开发人员、设计师和软 件架构师共享,以便在整个实现周期内帮助大家协同活动。一个成熟 的方法论还可以随着时间的发展,随着每个团队不断发现改善和精简 过程的方式而得到精炼,却不会对实现细节产生不利的影响。实际上, 当实现细节和设计过程两者都有清晰的定义并相互分离时,实现细节 专题 | Topic 的改变(比如采用哪个平台、OS、框架和 UI 样式)可以独立于设计过 程。 API 设计七步法 接下来我们要对 Richardson 和 Amundsen 合著的《REST 风格的 Web API》一书中所介绍的设计方法论做简要地概述。因为篇幅所限,我们 不能深入探讨这一过程中的每一步骤,但这篇文章可以让你有个大概 的认识。另外,读者可以用这篇概述作为指南,根据自己组织的技能 和目标开发一个独有的 Web API 设计过程。 说明:是的,7 步看起来有点儿多。实际上清单中有 5 个步骤属于设计, 额外还有两个条目是实现和发布。最后这两个设计过程之外的步骤是 为了提供一个从头到尾的体验。 你应该计划好根据需要重新迭代这些步骤。通过步骤 2(绘制状态图) 意识到在步骤 1(列出所有组成部分)有更多工作要做。当你接近于写 代码(步骤 6)时,可能会发现第 5 步(创建语义档案)中漏了一些东 西。关键是用这个过程暴露尽可能多的细节,并愿意回退一步或者两 步,把前面漏掉的补上。迭代是构建更加完整的服务画面以及澄清如 何将它暴露给客户端程序的关键。 步骤 1 : 列出所有组成部分 第一步是列出客户端程序可能要从我们的服务中获取的,或要放到我 们的服务中的所有数据片段。我们将这些称为语义描述符。语义是指 它们处理数据在应用程序中的含义,描述符是指它们描述了在应用程 序自身中发生了什么。注意,这里的视点是客户端,不是服务器端。 将 API 设计成客户端使用的东西很重要。 比如说,在一个简单的待办事项列表应用中,你可能会找到下面这些 语义描述符:  id:系统中每条记录的唯一标识符;  title:每个待办事项的标题;  dateDue:待办事项应该完成的日期;  complete:一个是/否标记,表明待办事项是否已经完成了。 在一个功能完备的应用程序中,可能还会有很多语义描述符,涉及待 办事项的分类(工作、家庭、园艺等),用户信息(用于多用户的实 现)等等。不过为了突出过程本身,我们会保持它的简单性。 专题 | Topic 步骤 2 : 绘制状态图 下一步是根据建议的 API 绘制出状态图。图中的每个框都表示一种可 能的表示——一个包含在步骤 1 中确定的或多个语义描述符的文档。 你可以用箭头表示从一个框到下一个的转变——从一个状态到下一个 状态。这些转变是由协议请求触发的。 在每次变化中还不用急着指明用哪个协议方法。只要标明变化是安全 的(比如 HTTP GET),还是不安全/非幂等的(比如 HTTP.POST), 或者不安全/幂等的(PUT)。 说明:幂等动作是指重复执行时不会有无法预料的副作用 。比如 HTTP PUT ,因为规范说服务器应该用客户端传来的状态值替换目标资 源的已有值,所以说它是幂等的。而 HTTP POST 是非幂等的,因为规 范指出提交的值应该是追加到已有资源集合上的,而不是替换。 在这个案例中,我们这个简单的待办事项服务的客户端应用程序可能 需要访问可用条目的清单,能过滤这个清单,能查看单个条目,并且 能将条目标记为已完成。这些动作中很多都用状态值在客户端和服务 器之间传递数据。比如 add-item 动作允许客户端传递状态值 title 和 dueDate。下面是一个说明那些动作的状态图。 专题 | Topic 这个状态图中展示的这些动作(也在下面列出来了)也是语义描述符-- 它们描述了这个服务的语义动作。  read-list  filter-list  read-item  create-item  mark-complete 在你做这个状态图的过程中,你可能会发现自己漏掉了客户端真正想 要或需要的动作或数据项。这是退回到步骤 1 的机会,添加一些新的 描述符,并/或者在步骤 2 中改进状态图。 在你重新迭代过这两步之后,你应该对客户端跟服务交互所需的所有 数据点和动作有了好的认识和想法。 步骤 3:调和魔法字符串 下一步是调和服务接口中的所有“魔法字符串”。“魔法字符串”全 是描述符的名称--它们没有内在的含义,只是表示客户端跟你的服务通 讯时将要访问的动作或数据元素。调和这些描述符名称的意思是指采 用源自下面这些地方的,知名度更高的公共名称:  Schema.org  microformats.org  Dublin Core  IANA Link Relation Values 这些全是明确定义的、共享的名称库。当你服务接口使用来自这些源 头的名称时,开发人员很可能之前见过并知道它们是什么意思。这可 以提高 API 的可用性。 说明:尽管在服务接口上使用共享名称是个好主意,但在内部实现里 可以不用(比如数据库里的数据域名称)。服务自身可以毫不困难地 将公共接口名称映射为内部存储名称。 以待办事项服务为例,除了一个语义描述符 create-item,我能找到所有 可接受的已有名称。为此我根据 Web Linking RFC5988 中的规则创建了 一个具有唯一性的 URI。在给接口描述符选择知名的名称时需要折中。 它们极少能跟你的内部数据存储元素完美匹配,不过那没关系。 这里是我的结果:  id -> 来自 Dublin Core 的 identifier 专题 | Topic  title - 来自 Schema.org 的 name  dueDate -> 来自 Schema.org 的 scheduledTime  complete -> 来自 Schema.org 的 status  read-list -> 来自 IANA Link Relation Values 的 collection  filter-list -> 来自 IANA Link Relation Values 的 search  read-item -> 来自 IANA Link Relation Values 的 item  create-item ->用 RFC5988 的 http://mamund.com/rels/create-item  mark-complete - 来自 IANA Link Relation Values 的 edit 经过名称调和,我的状态图变成了下面这样: 步骤 4:选一个媒体类型 API 设计过程的下一步是选一个媒体类型,用来在客户端和服务器端之 间传递消息。Web 的特点之一是数据是通过统一的接口作为标准化文 档传输的。选择同时支持数据描述符(比如"identifier"、"status"等)和 动作描述符(比如"search"、"edit"等)的媒体类型很重要。有相当多可 用的格式。 在我写这篇文章时,一些顶尖的超媒体格式是 (排名不分先后):  超文本标记语言 (HTML)  超文本应用程序语言(HAL) 专题 | Topic  Collection+JSON (Cj)  Siren  JSON-API  交换表达式的统一基础 (UBER) 让所选择的媒体类型适用于你的目标协议也很重要。大多数开发人员 喜欢用 HTTP 协议做服务接口。然而 WebSockets、XMPP、MQTT 和 CoAP 也会用--特别是对于高速、短消息、端到端的实现。 在这个例子中,我会以 HTML 为消息格式,并采用 HTTP 协议。HTML 有所有数据描述符所需的支持(
还剩82页未读

继续阅读

pdf贡献者

patrick002

贡献于2015-03-15

下载需要 3 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf