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并不是一件难事。但最后还是那句话，形态仅仅只是外在，练功之人修炼好内力才是根本，没有必要为了迎合一种所谓的潮流而去盲目的选择形态，因为服务提供商将要面对的是高过网站上百甚至更高流量的访问调用，如何满足开发者业务以及非业务（稳定，高效，安全）的需求，才是最大的挑战。