Open API 分析、实践和思索

SOA、SAAS、云计算等等热捧概念词汇层出不穷，也让很多开发者去重新审视未来的软件开发将会何去何从。而 Open API 的出现，其实已经给国外的互连网应用开发者带来了一种新的创新思维，一种新的开发模式，将 SOA 的信息互通的理念贯穿到整个互连网行业，让更多的“草根”开发者用创新思维将互联网信息的价值最大化。

对于国内的开发者来说，在 SNS 热潮中第一次接触了 Open API，但这仅仅只是开始。SNS 提供的 API 以及现有的一些分享类网站提供的 API，仅仅只是 Open API 中的一角，所能给开发者带来的想象空间，以及所能够产生的商业价值还是十分有限。

今年很多时间都投入到 Open API 集成平台的设计和开发中，因此对于 Open API 有一些自己的收获和感想，同时希望通过对 Open API 的介绍、实践能让更多的人了解和投入到这种新兴开发模式中。这种开发模式是一种挑战，一种创新更是一种机会。

一. Open API 的介绍

Open API 的发展

互联网应用最重要的就是创意和及时响应变更这两点。传统软件拚专业化和服务质量，但盗版，同质竞争，对用户个性化需求的服务支持，使得客户和软件生产商都没有得到满意结果。SAAS 模式的提出，其实部分也说明了市场和客户对于互联网应用的需求日趋增强，长尾理论更是让很多草根开发者看到了未来。但互联网应用是否仅仅就把传统软件搬上网就算是适应潮流，改制创新了呢？其实不然，互联网开放带来的模仿远比盗版可怕，软件的开发周期长，版本迭代周期长，让传统软件开发模式下的开发人员疲于满足用户需求。而最重要的创意，传统软件专注于专业化，而专业化带来的就是我们过去说 SOA 需要解决的那些信息竖井，只有将不同行业的信息串联打通，原有的数据资源才会体现出其更大的商业价值。 因此 Open API 出现了，起初也许仅仅是互联网企业内部的一种需求，因为企业规模日趋庞大，组织内部的协作也需要模块化和服务接口化，随着业务的梳理以及抽象，服务逐渐不仅仅可以满足内部交互，同时对外开放给一些商业合作伙伴，随之而来的就是数据资源价值的体现让开放服务的企业得到了回报。当越来越多的互联网企业将自己内部的业务作为服务提供给外部使用者的时候，服务的发布，流程的规范化也逐渐形成。REST 作为一种轻量级服务交互规范也得到了新一代互联网企业的认同，加上 RSS，JSON，XML 已经广泛使用的多种数据格式，让 Open API 有了公共的基础，也为 Open API 的开发者集成开发提供了最基本的保障。

当前国外的 Open API 不论是种类，提供商的服务质量，规范化和使用情况都在这一年里面有了很大的提升，可以说已经由初期的发展转到了较为成熟的发展。而国内，就开放的企业，提供商的服务提供成熟度，以及安全等方面的措施，都仅仅只是起步，不过好处在于有可借鉴的模式。不过，明年随着 Open API 带来的商业价值逐渐体现，会让更多的人加入到互联网这种新的应用开发模式中来，同时也会给很多开发者，特别是个人和小团队开发者带来机遇。互联网行业就是一个以小博大的行业，当面对成千上万的新兴资源的时候，创意加行动才是成功的基石。

Open API 的形态

就现在互联网上 Open API 的形态来看，主要分成两种：标准 REST 和类 REST(也可以叫做 RPC 形态)。

RPC 形态其实就是 Web Service 的一种延续，只是少了繁重的解析、安全规范等。Flickr 的 Open API 大部分就是这种形态，看看下面的服务请求 URL：

 
http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value

服务请求地址包括了两部分：1. 服务的总入口地址 http://api.flickr.com/services/rest/。2. 服务方法以及参数。这和过去的 RPC 模式就是一样的，只是通过 Http 方式请求，返回的是可以指定格式数据内容。

REST 形态主要有这么几点特点：1. 服务地址就是资源定位地址。2. 服务操作就是 Http 请求中的方法类型（GET,POST,DELETE,PUT），这其实是抽象现实当中对于服务的增删改查操作。Google 大部分的 REST API 就采用了标准的 REST 风格，服务请求地址 URL 如下：

 
http://www.google.com/calendar/feeds/wenchu.cenwc@alibaba-inc.com/allcalendars/full

这个服务请求地址是用来定位以我阿里巴巴邮箱注册的 Google 帐号的所有日程安排，通过在 Http 消息头中配置 Get、Post、DELETE、PUT 可以对我的日程进行操作，而无须登陆到 Google 上去操作。（后面部分的实践中会有部分介绍如何通过后台 Java 代码直接操作）

对于 REST 形式的讨论在网上一直有，但其实这种讨论没有什么意义，其实就好比争论吃饭是否一定要用筷子，没有什么技术是“万能药”，也没有什么技术好于不好，只有使用它的人是否有足够的智慧把它应用到适合的场景中。

对于类 REST 的形态来说优点在于对于原有系统的改造较小，“当前”用户使用接受度更高一些，对于逻辑抽象来说更加容易。而 REST 风格的优点在于，资源容易管理，系统扩展容易，权限控制可以部分依托于已有的传输协议。两者的缺点其实就是对方的优点。采取什么模式，其实还是要根据企业本身情况来看，类似于淘宝采用的就是类 REST 方式，而未来支付宝将会采用 REST 的方式，前者要改造整个系统架构和资源数据结构基本是不太可能完成的任务，后者对于业务逻辑梳理以及在现有内部 SOA 架构体系下抽象出 REST 风格的 API 并不是一件难事。但最后还是那句话，形态仅仅只是外在，练功之人修炼好内力才是根本，没有必要为了迎合一种所谓的潮流而去盲目的选择形态，因为服务提供商将要面对的是高过网站上百甚至更高流量的访问调用，如何满足开发者业务以及非业务（稳定，高效，安全）的需求，才是最大的挑战。

Open API 的类型

这里指的类型，主要从提供服务本身内容来看。当前服务类型主要可以分成三种：数据型，应用型，资源型。

现在很多 SNS 网站的 Open API 就是属于数据型，也就是将自身的数据开放，让应用开发者根据已有的数据进行二次应用开发。

应用型其实应该是数据型结合的比较紧密，Flickr 的图片搜索，Google 的日程，地图（地图数据其实可以自己定义）等等都是属于应用型。应用型的数据输入可以是外部的数据，也可以是基于已有的数据资源进行处理。

资源型的代表就是 Amazon，Amazon S3 就是典型的资源型，当然 Flickr 的图片存储服务等也可以属于资源型。其实今年还有一个被炒得火热的话题就是云计算，在云计算的背后就是需要提供这么一个资源型的服务，Amazon EC2 如果离开了 S3，也就无法存在。其实这种类型的服务也是一种未来的趋势，未来互联网应用如果要培植草根级开发者，就需要有这样的温室，Google 的 App engine 如果在多一些语言环境版本，那么会让更多的开发者有梦想实现的空间。

在回过头来看三种类型的服务，其实有着很强的层次关系，就如下图：

图 1 Open API 的类型

Open API 交互的数据格式

对于互联网应用来说，最大的特点也是最大的优点就是基于 Http 协议开发成为应用开发的统一标准。对于使用的语言，采用的操作系统和应用部署平台都没有太多的限制。Web Service 采用 xml 作为数据传输承载，制定了解析标准（以及后来安全，转发等标准）为开发者异构系统的信息交互带来了可能，也成为至今为止应用最广泛的服务集成方式。而随着 Web2.0 发展，RSS、Atom、JSON 的大规模应用，对于数据交互格式有了更多的选择。

服务请求就是标准的 Http 的请求，对于文件类上传的服务采用 HTTP Multipart 的格式。编码方式基本都采用 UTF-8 的编码方式。

在 Open API 的数据返回格式方面，大部分的网站优先提供 Xml、JSON 的数据返回，Google 定义的 GData 就是在 Atom 基础上作了扩展，还有一些网站提供了 php 的数据返回。同时有些网站会在 Open API 的基础上作更高的一层封装，类似于 Google Map，可以通过 java script 框架来直接使用。

当前国外的 Open API 使用状况

我这里只列了前四名的一个比例对照, 但是前面四名占有总的 Mash-up 的比例已经高达 80% 左右。

从这个占有率可以看出，API 首先吸引开发者的应该是 API 应用场景是否广泛，Google Map 其实就是最好的说明，地图类服务可以和各种行业结合起来为人们生活服务。其次就是 API 的专业化，后面三位这方面都是本类服务中作的最出色或者说是暂时还没有人可以作到的。Flickr 的服务就是围绕着图片，但是 Flickr 对于图片 Tag 专业性的设计让使用者的需求得到了最大的满足，同时也为开发者提供了很多隐性的资源。YouTube 借助着 Google 在搜索领域的强大优势以及自身的行业能力也吸引了广大的开发者。而 Amazon 多层次的 API 结构化设计，为开发者提供了整套的开发解决方案（EC2,S3,SQS,SimpleDB 作为基础的 Framework; FPS,DevPay 作为配套支付服务支持，Alexa Web Search 作为搜索），同时加上自身的强大的电子商务基础，也成为了很多开发者的首选。

其实从国外的 Open API 来看，如果要成为开发者的服务提供商首选，那么就需要在服务特色，服务质量，服务配套化（社区，SDK，开发框架，整体解决方案）上作文章。很多企业已经有了吸引人的数据资源（类似于淘宝，YouTube，Flickr），或者拥有行业内强大的专业能力（类似于 Google 的搜索，地图，支付宝的支付）都可以比较容易的占有市场优势，而类似于国内现在很多 SNS 网站商业模式已经被复制的差不多了，数据内容其实也部分上下，因此如何能够做好服务特色，质量，配套化才是未来在 Open API 领域走的更远的基石。

二． Open API 的实践

Open API 实践部分根据授权策略的不同和使用方式的不同分成几阶段内容，完整的代码可以去 Google Code 下载（ http://rest-demo.googlecode.com/files/demostore.rar ）。

注：代码中的部分用户名和密码以及应用 id 都需要采用自己申请的内容作替换，代码都是 Java 的后台程序代码，主要考虑实践即可，同时这部分代码仅仅是作为测试，结构和错误处理都是没有作太多的关注。

三． 类授权策略

免授权只需要开发者申请应用 ID 即可使用服务。应用授权是最基础的 Open API 开发授权策略，作用是让服务提供商能够核对每一次服务请求者的身份，同时也保证了服务开发商的自身利益，与免授权之间的区别就是是否需要在请求中带上数字签名来交验请求者身份。用户授权一般是基于应用授权之上的更高层次的授权认证，为了保障使用应用的终端用户数据不会在用户不知情或未授权的情况下被访问和修改，使用户隐私泄露或者蒙受损失。

免授权和应用授权类服务的开发

Yahoo 的 Search 引擎以及 Boss 服务（Build your Search Service）都是属于免授权类服务。

首先，上 Yahoo 开发者网站申请应用身份 ( http://developer.yahoo.com/），这里首先需要拥有一个 Yahoo 的 Id，然后即可申请应用 Id，一个开发者可以申请多个应用 Id。

客户端测试代码片段如下：

接下来就看看运行效果吧：

testYahooSearch()的运行结果如下：

测试运行结果是搜索结果集的 xml 描述，可以根据 ImageSearchResponse.xsd 来解析返回的内容。

testBossSearch()运行的结果如下：

测试运行的结果是已经经过 XPath 初步处理的结果，提供了下一页的入口 URL 地址，以及本次搜索出来的结果集。

通过阿里软件服务集成平台访问淘宝非用户隐私信息类 API 就属于应用授权类服务。与上面范例差异在于调用发送方法时传入了 secretcode，进行参数签名（参数中增加了时间戳）。

由上面的例子可以看出，对于公开信息的访问，Open API 接入简单，使用方便。

用户授权类服务的开发

用户授权类服务，首先就要解决如何让用户能够在知情的情况下授权给应用开发商获取和操作用户个人的数据，实现用户需求。在传统意义上通常会让用户输入某一个网站的用户名和密码，就类似于现在的很多 SNS 让用户输入 msn,qq 帐号来获取用户好友信息，但是其实这样对于用户来说风险很大，特别是一些个人隐私性很强的信息或者是涉及到金钱的操作。因此现在大部分的服务提供商采取的是 OAuth 方式的认证或者是类似于 OAuth，OAuth 的具体细节我就不在这里赘述了，网上有很详细地资料，这里就大致把流程原理画一下。

图 2 OAuth 流程

这里将采用 Flickr 图片上传作为测试范例：

首先，还是要拥有 Flickr 的帐号，然后同时去申请应用 id。

具体的代码片断如下：

看看执行效果：

首先控制台会输出：if done then input ‘ok’ to console!，同时弹出 IE 窗口如下：

输入用户名和密码以后会看到如下界面，就表示授权成功了。

在控制台中输入 ok，然后回车。看到如下提示：

然后就输入你需要上传的图片的地址，例如我输入我的 blog 的头像地址： http://avatar.profile.csdn.net/3/5/1/1_cenwenchu79.jpg。然后回车，会看到新弹出一个页面，里面就是上传到你 Flickr 中的图片。

以上就是一次用户授权 API 的完整操作，对比应用授权，个人授权相对来说会比较复杂一些，同时根据调用应用的不同，也会有不同的授权流程（Web 应用，桌面应用，手机应用）。但就现在国内外的 Open API 使用来看，大致的思想都比较相似，也就是 OAuth 的思想，但是细节部分会有不少差异，例如 Token 时效，维护方，操作范围等。

Mash-up 的范例

Mash-up 在基维百科中定义是这样的（In web development, a mash-up is a web application that combines data from more than one source into a single integrated tool）。数据的一种集成。其实 Open API 真正的目的就是希望够让信息在交互中产生更大的价值。

这个范例的场景是淘宝卖家上传上品信息的同时需要有商品的图片，通常商家就不得不自己再去找一些符合自己商品的缩略图，这里我采用上面使用过的 Yahoo BOSS 搜索缩略图，将符合条件的缩略图选择一个作为商品的描述图片再上传到淘宝。这样就将整个淘宝卖家编辑上传宝贝的流程简化了，并且对于商品图片描述来说会有更多更好的选择。

淘宝的 Open API 都通过阿里软件的服务集成平台发布（后面章节会对服务集成平台有介绍和描述），具体的使用流程其实和前面描述的两种服务获取方式一样，只是在用户授权方面对于应用开发者来说更加简便。

第一步，还是申请应用帐号和安全密码，不过需要首先拥有一个阿里巴巴中文站或者淘宝、阿里软件的帐号，然后登录 http://isv.alisoft.com/isv/portal/home/home.jspa，然后选择开发者联盟的标签，里面有说明文档和指南。

第二步，你需要有一个淘宝帐号，并且开了网店。

第三步，客户端代码，代码片断如下：

运行结果：

首先控制台会输出：if done then input ‘ok’ to console! 然后会有 IE 弹出界面如下：

输入用户信息以后将会进入如下页面：

点击确认，然后关闭网页。在控制台中输入 ok，并且回车。此时就会发现，淘宝卖家中的一个宝贝被修改了价格和图片，不过由于淘宝店的更新会有滞后，因此需要去我的淘宝里面看正在出售中的宝贝。

可以看到，冰激凌图片已经上传到了地毯上去了，这里当然只是试验看效果而已。

三. 服务集成平台

经过前面的介绍和实践两部分，在 Open API 在概念和实际操作上都有了一定的理解和认识，这里就再谈谈服务集成平台的作用、角色和定位。这里大致描述一下集成平台当前的实现点，这些实现点也就是服务集成平台的价值所在。

服务集成平台（SIP）的角色和作用

图 3 SIP Role

ISV（独立软件开发商）最关心什么？

1. 服务资源是否丰富。这关系着是否能够创新。
2. 服务质量是否有保证。这关系着是否能够满足用户最基本的需求。
3. 开发集成是否便利。这关系着开发成本。

ISP（独立服务提供商）最关心什么？

1. 服务安全性是否可靠。如果损害到自身或者用户利益，则就失去了原来开放的初衷。
2. 是否有足够多的应用开发者使用服务。
3. 服务的非业务性需求是否可以满足。（服务监控告警，计费，统计分析等）

SIP 是连接 ISV 和 ISP 的“桥梁”。它能解决什么双方最关心的什么问题？

1. 丰富的 ISV 资源以及丰富的 ISP 资源。这其实是一个良性循环的过程，就好比一个建材市场，买家和卖家数量远远要比在单独一家实体店中多，从淘宝的 B2C 模式就可以看出，市场大了以后传统的“大鳄”都要聚集人气。
2. 统一安全标准和多种控制策略，即保证了 ISP 的安全，又能够让 ISV 开发起来方便。在前面实践过程中可以很明显的看到，众多的应用 id，各自的安全流程，让开发者 Mash up 无形中增加了很大的开发成本和维护成本。
3. SIP 目的就是让 ISP 专注于业务服务的开发，而将非业务性的需求，如安全，服务监控预警，日志分析统计，计费，社区等都一揽子解决。这样既解决了 ISP 的第三个问题，同时也为 ISV 关心的服务质量无形中作了促进。

在年初的时候，分析和研究国外的 Open API 时，感觉类似于 SIP 形态的产品在国外还没有，大家都是各做各的，但这阵子回过头来看，YouTube 和 Google 开放平台，Flickr 和 Yahoo 开放平台，这些平台都属于 SIP 形态的产品，而且 Google 要比当前我们做的 SIP 还要更进一步，那就是数据格式规范化 (GData)，而 SIP 当前仅仅只是做到流程规范化。

那是否任何公司都适合去做 SIP 这类形态的平台呢，这不仅仅是技术问题，还是一个资源的问题。阿里巴巴每一家子公司都有实力去做一个这样的开放平台，但各自独做一套的结果就是资源浪费，同时技术没有得到积累（SIP 技术积累是在 ISV 和不同形态的 ISP 接入中逐渐产生的），最重要的是这些子公司其实真正需要关注的是如何将业务和数据开放给开发者，吸引更多的开发者来构建出围绕 Open API 的创新应用，最大化数据和服务的商业价值。

服务集成平台功能特性

服务路由

服务集成平台就好比硬件里面的“路由器”，服务调用者只需要提供服务注册的名称，就可以调用到某一个服务提供商提供的服务，对于调用者来说无需关心此服务的地址以及提供者。

根据现阶段的服务集成来看，主要分成四类的服务路由，同步服务路由，异步服务路由，订阅服务路由，大数据量上传服务。同步服务路由就是普通的 Http 无状态单次请求和响应。异步服务路由应用于服务提供商提供的服务无法在当时处理完毕，先返回一个请求响应，当服务处理结束以后再将服务处理结果返回给服务调用者（短信业务就是一种异步服务）。订阅服务和互联网上 RSS 之类的订阅十分相似，服务调用者只需要订阅服务即可获得服务提供商推送的服务内容。大数据量上传服务其实也是属于同步服务，但是由于消耗资源和性能压力不同，因此被单独作优化处理。

对于服务形态不同，服务路由需要支持 REST 风格的服务路由和类 REST 风格服务的路由，但对于开发者来说，调用的方式都是用服务名称来路由。

正式环境和测试环境的隔离和切换

对于服务开发者来说，在应用开发期间需要有外部测试环境的支持，在商用以后需要有正式环境支持，同时两个环境的切换需要尽量的简单。

服务集成平台支持服务提供商提供测试环境和正式环境的不同服务路由，同时两套环境切换成本低。当服务提供商只有一套环境的时候可以根据策略配置的不同，对调用者访问的范围，频度，次数作限制，保证测试服务不影响正式服务。

安全

提供对应用身份认证以及服务提供商身份认证的支持，采用多种数字签名算法实现基本的身份认证，支持 IP 白名单和动态算法更新后端插件提供更高级别的服务安全保证。

细化了用户授权流程。对于用户 Token 细分为请求级别和会话级别，同时对于会话级别的权限操作，失效时间可根据服务提供商的配置自定义。同时平台托管维护每个应用每个用户的多身份绑定 Token，降低服务提供商开发维护成本。

服务提供商可配置服务访问量控制和频率控制（所有应用或者单个应用）。也支持配置需要订购才可以使用的服务（有限次数订购，无限次数订购）。

支持多级服务安全策略配置，为服务配置（无授权，应用授权，用户授权，可选用户授权）等多种级别的安全策略。注：可选用户授权是指如果没有被用户授权的情况下使用接口将返回部分公开数据，而在用户授权情况下使用则返回全部的私有和公开数据。

对服务提供商多级分类，提供不同的安全策略组合。

监控与告警

服务使用者服务使用出错监控和告警。

服务提供商提供的服务可用性，超时状况的监控和告警。

服务集成平台服务处理状况，内部模块运行状况监控和告警。

日志采集与统计分析

高并发下日志采集异步处理，采集服务正常访问和异常访问日志，采集用户绑定类，异步服务类，平台内部服务类等特殊日志。

每日，每周，每月访问日志统计分析，基础报表和趋势分析图的创建。

支持分析结果预警配置。

历史统计数据管理和归档。

平台内置服务

平台为服务提供商以及服务调用者提供了平台级别的服务，为开发商和服务提供者获取平台业务数据以及运行期配置安全策略提供方便。

平台提供一系列平台模块监控、配置、重置服务，支持在线问题查找、定位、解决的一套机制。

非功能性需求（当前情况）

性能：压力测试单机 500 并发用户 1600+ 的 tps，多机处理能力线性增长。

模块化：内部处理模块化结构，支持运行期配置、装载、卸载。

容错：服务集成平台核心数据都缓存在 Memcache 中，因此 Memcache 集群以及容错策略的扩展都为平台稳定和容错作了基础保证。

配套支持

通过 ISV,ISP,Admin 三个 Portal，使开发者，服务提供商以及后台维护人员能够自主维护基本信息和查看相关数据。

为开发者提供社区，测试区的支持，并且提供开发工具包和文档，方便开发。

扩展集成

支持不同平台的服务集成。支持 Google,Flickr,Yahoo 等等不同的服务平台的服务集成，当前还没有完全将安全体系集成，只能够支持安全流程透传，消息数据完整过滤。

服务集成平台的一些发展趋势

1. 数据集成和流程集成
   当前很多服务都是基础的数据型服务，使用者通过数据筛选获取相应的数据，然后展现给用户，这些服务的集成相对来说功能比较单一，流程也不复杂。但随着服务提供商的发展，数据类型服务将会作为基础服务的一部分，而越来越多业务处理型服务会成为使用者的首选，此时，如何让服务和服务之间数据互通，服务可以通过一定的描述编排，就会变得越来越有价值，就如前面提到的，Google 采用 GData 作为数据规范格式，同时对于安全流程的统一制定，为第二阶段的集成打下了基础。
2. 服务基础平台间的互通
   最近 Open ID 也再次由于各大网站的支持而被人们广泛关注，在未来 Open API 体系中，伴随着 Open ID 的发展，服务基础平台之间的服务互通也将会变得越来越容易，但是数据的安全性也会对每个服务平台要求更高。
3. 服务集成平台的层次化
   在这篇文章的介绍中仅仅介绍的是最基础的 Open API 的 Mash up，其实当前已经有更高层次的 Mash up 被广为使用，JavaScript、ActionScript、Flash/Flex 这些技术使得展现更为灵活和丰富。因此未来的服务集成平台将会层次化，从数据集成到流程集成到 UI 集成，会成为一套自下而上的解决方案，适合各种场景的裁剪选择。

四. 对 Open API 的一些思索和感触

不同角色，不同收获

平台开发者：

这是我的本职工作和角色。当淘宝等服务提供商的服务接上来以后我就要为它的安全和稳定负责。当 SIP 一旦出现问题，那么服务提供商和软件开发商将都无法再正常工作，套用蜘蛛侠的一句话：“能力越大，责任越大”。作平台的尤为如此。

服务提供商：

服务提供商接触的最多的就是淘宝的同学，首先看到的就是做一个服务提供商很不容易，要把原有系统中复杂的逻辑抽象出来并不是抽象一个公用函数那么简单，同时对于模块化，边界性，容错性方面的要求要远远高于封闭系统开发本身，因为你现在要面对的是倍于原有访问量上百甚至上千的调用者，对任何一个小疏漏都可能带来灾难性的影响。

软件开发商：

在写这个文档以前，最多也就是写几个测试的 Demo 来测试 SIP 环境中的服务，在淘宝 API 讨论群中会看到很多新的或者老的 ISV 在抱怨或者询问一些自己觉得很简单的问题（例如签名等等），同时在监控中也看到很多及其简单错误统计数都会有很高的比例。但是经历过这次对于各种各样国内国外的 API 的开发，让我深刻体会到了开发者的一些痛苦（当然我没有去使用各个开发社区的第三方语言开发包，这也增加部分的开发难度），我也曾因为签名问题在豆瓣 API 测试的时候折腾了半天，在调试 Google Calendar 的时候不得不跟踪开发包代码才找到了一些隐晦的设置通过测试。其实 Open API 在国内国外都没有完全可以称得上成熟，因此开发者其实是最容易受到影响的。同时他们面对着最难应付的客户，平台或者服务提供商出现问题，客户最先抱怨的也是服务开发商，因此作为平台开发者和 ISP 其实都要给与一定的支持和帮助，这样才会走向更好的良性循环。

其实上面说的那些无非都是大家最长说的换位思考，一个新兴的开发模式需要各方合作才会走向良好的发展方向。

创意就是财富

记得前一阵子支付宝能够在上海交水电费引起了很多人关注，杭州本地论坛中都有很多人在问：“什么时候杭州能够也用支付宝交水电费就好了”。其实如果开放了支付服务和水电缴费服务，这种 Mash up 的应用又有什么难的呢？你都可以直接每个自然月通过 Google Calendar 设置好日程安排，自动缴完所有的费用，然后短信提示一下即可。未来当各行各业发现了自身资源的潜在价值以后，以服务的方式通过平台互通，那么创意就是财富。

作者介绍：岑文初，就职于阿里软件公司研发中心平台一部，任架构师。当前主要工作涉及阿里软件开发平台服务框架（ASF）设计与实现，服务集成平台（SIP）设计与实现。没有什么擅长或者精通，工作到现在唯一提升的就是学习能力和速度。个人 Blog 为： http://blog.csdn.net/cenwenchu79 。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。