搜索
OpenAPI分析、实践和思索SOA、SAAS、云计算等等热捧概念词汇层出不穷，也让很多开发者去重新审视未来的软件开发将会何去何从。而OpenAPI的出现，其实已经给国外的互连网应用开发者带来了一种新的创新思维，一种新的开发模式，将SOA的信息互通的理念贯穿到整个互连网行业，让更多的“草根”开发者用创新思维将互联网信息的价值最大化。。对于国内的开发者来说，在SNS热潮中第一次接触了OpenAPI，但这仅仅只是开始。SNS提供的API以及现有的一些分享类网站提供的API，仅仅只是OpenAPI中的一角，所能给开发者带来的想象空间，以及所能够产生的商业价值还是十分有限。今年很多时间都投入到OpenAPI集成平台的设计和开发中，因此对于OpenAPI有一些自己的收获和感想，同时希望通过对OpenAPI的介绍、实践能让更多的人了解和投入到这种新兴开发模式中。这种开发模式是一种挑战，一种创新更是一种机会。一.OpenAPI的介绍OpenAPI的发展互联网应用最重要的就是创意和及时响应变更这两点。传统软件拚专业化和服务质量，但盗版，同质竞争，对用户个性化需求的服务支持，使得客户和软件生产商都没有得到满意结果。SAAS模式的提出，其实部分也说明了市场和客户对于互联网应用的需求日趋增强，长尾理论更是让很多草根开发者看到了未来。但互联网应用是否仅仅就把传统软件搬上网就算是适应潮流，改制创新了呢？其实不然，互联网开放带来的模仿远比盗版可怕，软件的开发周期长，版本迭代周期长，让传统软件开发模式下的开发人员疲于满足用户需求。而最重要的创意，传统软件专注于专业化，而专业化带来的就是我们过去说SOA需要解决的那些信息竖井，只有将不同行业的信息串联打通，原有的数据资源才会体现出其更大的商业价值。因此OpenAPI出现了，起初也许仅仅是互联网企业内部的一种需求，因为企业规模日趋庞大，组织内部的协作也需要模块化和服务接口化，随着业务的梳理以及抽象，服务逐渐不仅仅可以满足内部交互，同时对外开放给一些商业合作伙伴，随之而来的就是数据资源价值的体现让开放服务的企业得到了回报。当越来越多的互联网企业将自己内部的业务作为服务提供给外部使用者的时候，服务的发布，流程的规范化也逐渐形成。REST作为一种轻量级服务交互规范也得到了新一代互联网企业的认同，加上RSS，JSON，XML已经广泛使用的多种数据格式，让OpenAPI有了公共的基础，也为OpenAPI的开发者集成开发提供了最基本的保障。当前国外的OpenAPI不论是种类，提供商的服务质量，规范化和使用情况都在这一年里面有了很大的提升，可以说已经由初期的发展转到了较为成熟的发展。而国内，就开放的企业，提供商的服务提供成熟度，以及安全等方面的措施，都仅仅只是起步，不过好处在于有可借鉴的模式。不过，明年随着OpenAPI带来的商业价值逐渐体现，会让更多的人加入到互联网这种新的应用开发模式中来，同时也会给很多开发者，特别是个人和小团队开发者带来机遇。互联网行业就是一个以小博大的行业，当面对成千上万的新兴资源的时候，创意加行动才是成功的基石。OpenAPI的形态就现在互联网上OpenAPI的形态来看，主要分成两种：标准REST和类REST(也可以叫做RPC形态)。RPC形态其实就是WebService的一种延续，只是少了繁重的解析、安全规范等。Flickr的OpenAPI大部分就是这种形态，看看下面的服务请求URL：=flickr.test.echo&name=value服务请求地址包括了两部分：1.服务的总入口地址。2.服务方法以及参数。这和过去的RPC模式就是一样的，只是通过Http方式请求，返回的是可以指定格式数据内容。REST形态主要有这么几点特点：1.服务地址就是资源定位地址。2.服务操作就是Http请求中的方法类型（GET,POST,DELETE,PUT），这其实是抽象现实当中对于服务的增删改查操作。Google大部分的RESTAPI就采用了标准的REST风格，服务请求地址URL如下：@alibaba-inc.com/allcalendars/full这个服务请求地址是用来定位以我阿里巴巴邮箱注册的Google帐号的所有日程安排，通过在Http消息头中配置Get、Post、DELETE、PUT可以对我的日程进行操作，而无须登陆到Google上去操作。（后面部分的实践中会有部分介绍如何通过后台Java代码直接操作）对于REST形式的讨论在网上一直有，但其实这种讨论没有什么意义，其实就好比争论吃饭是否一定要用筷子，没有什么技术是“万能药”，也没有什么技术好于不好，只有使用它的人是否有足够的智慧把它应用到适合的场景中。对于类REST的形态来说优点在于对于原有系统的改造较小，“当前”用户使用接受度更高一些，对于逻辑抽象来说更加容易。而REST风格的优点在于，资源容易管理，系统扩展容易，权限控制可以部分依托于已有的传输协议。两者的缺点其实就是对方的优点。采取什么模式，其实还是要根据企业本身情况来看，类似于淘宝采用的就是类REST方式，而未来支付宝将会采用REST的方式，前者要改造整个系统架构和资源数据结构基本是不太可能完成的任务，后者对于业务逻辑梳理以及在现有内部SOA架构体系下抽象出REST风格的API并不是一件难事。但最后还是那句话，形态仅仅只是外在，练功之人修炼好内力才是根本，没有必要为了迎合一种所谓的潮流而去盲目的选择形态，因为服务提供商将要面对的是高过网站上百甚至更高流量的访问调用，如何满足开发者业务以及非业务（稳定，高效，安全）的需求，才是最大的挑战。OpenAPI的类型这里指的类型，主要从提供服务本身内容来看。当前服务类型主要可以分成三种：数据型，应用型，资源型。现在很多SNS网站的OpenAPI就是属于数据型，也就是将自身的数据开放，让应用开发者根据已有的数据进行二次应用开发。应用型其实应该是数据型结合的比较紧密，Flickr的图片搜索，Google的日程，地图（地图数据其实可以自己定义）等等都是属于应用型。应用型的数据输入可以是外部的数据，也可以是基于已有的数据资源进行处理。资源型的代表就是Amazon，AmazonS3就是典型的资源型，当然Flickr的图片存储服务等也可以属于资源型。其实今年还有一个被炒得火热的话题就是云计算，在云计算的背后就是需要提供这么一个资源型的服务，AmazonEC2如果离开了S3，也就无法存在。其实这种类型的服务也是一种未来的趋势，未来互联网应用如果要培植草根级开发者，就需要有这样的温室，Google的Appengine如果在多一些语言环境版本，那么会让更多的开发者有梦想实现的空间。在回过头来看三种类型的服务，其实有着很强的层次关系，就如下图：图1OpenAPI的类型OpenAPI交互的数据格式对于互联网应用来说，最大的特点也是最大的优点就是基于Http协议开发成为应用开发的统一标准。对于使用的语言，采用的操作系统和应用部署平台都没有太多的限制。WebService采用xml作为数据传输承载，制定了解析标准（以及后来安全，转发等标准）为开发者异构系统的信息交互带来了可能，也成为至今为止应用最广泛的服务集成方式。而随着Web2.0发展，RSS、Atom、JSON的大规模应用，对于数据交互格式有了更多的选择。服务请求就是标准的Http的请求，对于文件类上传的服务采用HTTPMultipart的格式。编码方式基本都采用UTF-8的编码方式。在OpenAPI的数据返回格式方面，大部分的网站优先提供Xml、JSON的数据返回，Google定义的GData就是在Atom基础上作了扩展，还有一些网站提供了php的数据返回。同时有些网站会在OpenAPI的基础上作更高的一层封装，类似于GoogleMap，可以通过javascript框架来直接使用。当前国外的OpenAPI使用状况我这里只列了前四名的一个比例对照,但是前面四名占有总的Mash-up的比例已经高达80%左右。从这个占有率可以看出，API首先吸引开发者的应该是API应用场景是否广泛，GoogleMap其实就是最好的说明，地图类服务可以和各种行业结合起来为人们生活服务。其次就是API的专业化，后面三位这方面都是本类服务中作的最出色或者说是暂时还没有人可以作到的。Flickr的服务就是围绕着图片，但是Flickr对于图片Tag专业性的设计让使用者的需求得到了最大的满足，同时也为开发者提供了很多隐性的资源。YouTube借助着Google在搜索领域的强大优势以及自身的行业能力也吸引了广大的开发者。而Amazon多层次的API结构化设计，为开发者提供了整套的开发解决方案（EC2,S3,SQS,SimpleDB作为基础的Framework;FPS,DevPay作为配套支付服务支持，AlexaWebSearch作为搜索），同时加上自身的强大的电子商务基础，也成为了很多开发者的首选。其实从国外的OpenAPI来看，如果要成为开发者的服务提供商首选，那么就需要在服务特色，服务质量，服务配套化（社区，SDK，开发框架，整体解决方案）上作文章。很多企业已经有了吸引人的数据资源（类似于淘宝，YouTube，Flickr），或者拥有行业内强大的专业能力（类似于Google的搜索，地图，支付宝的支付）都可以比较容易的占有市场优势，而类似于国内现在很多SNS网站商业模式已经被复制的差不多了，数据内容其实也部分上下，因此如何能够做好服务特色，质量，配套化才是未来在OpenAPI领域走的更远的基石。二．OpenAPI的实践OpenAPI实践部分根据授权策略的不同和使用方式的不同分成几阶段内容，完整的代码可以去GoogleCode下载（）。注：代码中的部分用户名和密码以及应用id都需要采用自己申请的内容作替换，代码都是Java的后台程序代码，主要考虑实践即可，同时这部分代码仅仅是作为测试，结构和错误处理都是没有作太多的关注。三．类授权策略免授权只需要开发者申请应用ID即可使用服务。应用授权是最基础的OpenAPI开发授权策略，作用是让服务提供商能够核对每一次服务请求者的身份，同时也保证了服务开发商的自身利益，与免授权之间的区别就是是否需要在请求中带上数字签名来交验请求者身份。用户授权一般是基于应用授权之上的更高层次的授权认证，为了保障使用应用的终端用户数据不会在用户不知情或未授权的情况下被访问和修改，使用户隐私泄露或者蒙受损失。免授权和应用授权类服务的开发Yahoo的Search引擎以及Boss服务（BuildyourSearchService）都是属于免授权类服务。首先，上Yahoo开发者网站申请应用身份(），这里首先需要拥有一个Yahoo的Id，然后即可申请应用Id，一个开发者可以申请多个应用Id。客户端测试代码片段如下：接下来就看看运行效果吧：testYahooSearch()的运行结果如下：测试运行结果是搜索结果集的xml描述，可以根据ImageSearchResponse.xsd来解析返回的内容。testBossSearch()运行的结果如下：测试运行的结果是已经经过XPath初步处理的结果，提供了下一页的入口URL地址，以及本次搜索出来的结果集。通过阿里软件服务集成平台访问淘宝非用户隐私信息类API就属于应用授权类服务。与上面范例差异在于调用发送方法时传入了secretcode，进行参数签名（参数中增加了时间戳）。由上面的例子可以看出，对于公开信息的访问，OpenAPI接入简单，使用方便。用户授权类服务的开发用户授权类服务，首先就要解