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如果在多一些语言环

境版本，那么会让更多的开发者有梦想实现的空间。