Open-API分析、实践和思索

OpenAPI分析、实践和思索作者岑文初公布于2009年2月6日下午6时0分社区主题标签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：REST形状要紧有这么几点特点：1.服务地址确实是资源定位地址。2.服务操作确实是Http要求中的方法类型（GET,POST,DELETE,PUT），这事实上是抽象现实当中关于服务的增删改查操作。Google大部分的RESTAPI就采纳了标准的REST风格，服务要求地址URL如下：那个服务要求地址是用来定位以我阿里巴巴邮箱注册的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的实践注：代码中的部分用户名和密码以及应用id都需要采纳自己申请的内容作替换，代码差不多上Java的后台程序代码，要紧考虑实践即可，同时这部分代码仅仅是作为测试，结构和错误处理差不多上没有作太多的关注。三．类授权策略免授权只需要开发者申请应用ID即可使用服务。应用授权是最基础的OpenAPI开发授权策略，作用是让服务提供商能够核对每一次服务要求者的身份，同时也保证了服务开发商的自身利益，与免授权之间的区别确实是是否需要在要求中带上数字签名来交验要求者身份。用户授权一样是基于应用授权之上的更高层次的授权认证，为了保证使用应用的终端用户数据可不能在用户不知情或未授权的情形下被访咨询和修改，使用户隐私泄露或者蒙受缺失。免授权和应用授权类服务的开发Yahoo的Search引擎以及Boss服务（BuildyourSearchService）差不多上属于免授权类服务。客户端测试代码片段如下：接下来就看看运行成效吧：testYahooSearch()的运行结果如下：测试运行结果是搜索结果集的xml描述，能够按照ImageSearchResponse.xsd来解析返回的内容。testBossSearch()运行的结果如下：测试运行的结果是差不多通过XPath初步处理的结果，提供了下一页的入口URL地址，以及此次搜索出来的结果集。通过阿里软件服务集成平台访咨询淘宝非用户隐私信息类API就属于应用授权类服务。与上面范例差异在于调用发送方法时传入了secretcode，进行参数签名（参数中增加了时刻戳）。由上面的例子能够看出，关于公布信息的访咨询，OpenAPI接入简单，使用方便。用户授权类服务的开发用户授权类服务，第一就要解决如何让用户能够在知情的情形下授权给应用开发商猎取和操作用户个人的数据，实现用户需求。在传统意义上通常会让用户输入某一个网站的用户名和密码，就类似于现在的专门多SNS让用户输入msn,qq帐号来猎取用户好友信息，然而事实上如此关于用户来讲风险专门大，专门是一些个人隐私性专门强的信息或者是涉及到金钞票的操作。因此现在大部分的服务提供商采取的是OAuth方式的认证或者是类似于OAuth，OAuth的具体细节我就不在那个地点赘述了，网上有专门详细地资料，那个地点就大致把流程原理画一下。图2OAuth流程那个地点将采纳Flickr图片上传作为测试范例：第一，依旧要拥有Flickr的帐号，然后同时去申请应用id。具体的代码片断如下：看看执行成效：第一操纵台会输出：ifdonetheninput'ok'toconsole!，同时弹出IE窗口如下：输入用户名和密码以后会看到如下界面，就表示授权成功了。在操纵台中输入ok，然后回车。看到如下提示：然后就输入你需要上传的图片的地址，例如我输入我的blog的头像地址：/3/5/1/1_cenwenchu79.jpg。然后回车，会看到新弹出一个页面，里面确实是上传到你Flickr中的图片。以上确实是一次用户授权API的完整操作，对比应用授权，个人授权相对来讲会比较复杂一些，同时按照调用应用的不同，也会有不同的授权流程（Web应用，桌面应用，手机应用）。但就现在国内外的OpenAPI使用来看，大致的思想都比较相似，也确实是OAuth的思想，然而细节部分会有许多差异，例如Token时效，爱护方，操作范畴等。Mash-up的范例Mash-up在基维百科中定义是如此的（Inwebdevelopment,amash-upisawebapplicationthatcombinesdatafrommorethanonesourceintoasingleintegratedtool）。数据的一种集成。事实上OpenAPI真正的目的确实是期望够让信息在交互中产生更大的价值。那个范例的场景是淘宝卖家上传上品信息的同时需要有商品的图片，通常商家就不得不自己再去找一些符合自己商品的缩略图，那个地点我采纳上面使用过的YahooBOSS搜索缩略图，将符合条件的缩略图选择一个作为商品的描述图片再上传到淘宝。如此就将整个淘宝卖家编辑上传珍宝的流程简化了，同时关于商品图片描述来讲会有更多更好的选择。淘宝的OpenAPI都通过阿里软件的服务集成平台公布（后面章节会对服务集成平台有介绍和描述），具体的使用流程事实上和前面描述的两种服务猎取方式一样，只是在用户授权方面关于应用开发者来讲更加简便。第二步，你需要有一个淘宝帐号，同时开了网店。第三步，客户端代码，代码片断如下：运行结果：第一操纵台会输出：ifdonetheninput'ok'toconsole!然后会有IE弹出界面如下：输入用户信息以后将会进入如下页面：点击确认，然后关闭网页。在操纵台中输入ok，同时回车。现在就会发觉，淘宝卖家中的一个珍宝被修改了价格和图片，只是由于淘宝店的更新会有滞后，因此需要去我的淘宝里面看正在出售中的珍宝。能够看到，冰激凌图片差不多上传到了地毯上去了，那个地点所以只是试验看成效而已。三.服务集成平台通过前面的介绍和实践两部分，在OpenAPI在概念和实际操作上都有了一定的懂得和认识，那个地点就再谈谈服务集成平台的作用、角色和定位。那个地点大致描述一下集成平台当前的实现点，这些实现点也确实是服务集成平台的价值所在。服务集成平台（SIP）的角色和作用图3SIPRoleISV（独立软件开发商）最关怀什么？服务资源是否丰富。这关系着是否能够创新。服务质量是否有保证。这关系着是否能够满足用户最差不多的需求。开发集成是否便利。这关系着开发成本。ISP（独立服务提供商）最关怀什么？服务安全性是否可靠。如果损害到自身或者用户利益，则就失去了原先开放的初衷。是否有足够多的应用开发者使用服务。服务的非业务性需求是否能够满足。（服务监控告警，计费，统计分析等）SIP是连接ISV和ISP的“桥梁”。它能解决什么双方最关怀的什么咨询题？丰富的ISV资源以及丰富的ISP资源。这事实上是一个良性循环的过程，就好比一个建材市场，买家和卖家数量远远要比在单独一家实体店中多，从淘宝的B2C模式就能够看出，市场大了以后传统的“大鳄”都要集合人气。统一安全标准和多种操纵策略，即保证了ISP的安全，又能够让ISV开发起来方便。在前面实践过程中能够专门明显的看到，众多的应用id，各自的安全流程，让开发者Mashup无形中增加了专门大的开发成本和爱护成本。SIP目的确实是让ISP用心于业务服务的开发，而将非业务性的需求，如安全，服务监控预警，日志分析统计，计费，社区等都一揽子解决。如此既解决了ISP的第三个咨询题，同时也为ISV关怀的服务质量无形中作了促进。在年初的时候，分析和研究国外的OpenAPI时，感受类似于SIP形状的产品在国外还没有，大伙儿差不多上各做各的，但这阵子回过头来看，YouTube和Google开放平台，Flickr和Yahoo开放平台，这些平台都属于SIP形状的产品，而且Google要比当前我们做的SIP还要更进一步，那确实是数据格式规范化(GData)，而SIP当前仅仅只是做到流程规范化。那是否任何公司都适合去做SIP这类形状的平台呢，这不仅仅是技术咨询题，依旧一个资源的咨询题。阿里巴巴每一家子公司都有实力去做一个如此的开放平台，但各自独做一套的结果确实是资源白费，同时技术没有得到积存（SIP技术积存是在ISV和不同形状的ISP接入中逐步产生的），最重要的是这些子公司事实上真正需要关注的是如何将业务和数据开放给开发者，吸引更多的开发者来构建出围绕OpenAPI的创新应用，最大化数据和服务的商业价值。服务集成平台功能特性服务路由服务集成平台就好比硬件里面的“路由器”，服务调用者只需要提供服务注册的名称，就能够调用到某一个服务提供商提供的服务，关于调用者来讲无需关怀此服务的地址以及提供者。按照现时期的服务集成来看，要紧分成四类的服务路由，同步服务路由，异步服务路由，订阅服务路由，大数据量上传服务。同步服务路由确实是一般的Http无状态单次要求和响应。异步服务路由应用于服务提供商提供的服务无法在当时处理完毕，先返回一个要求响应，当服务处理终止以后再将服务处理结果返回给服务调用者（短信业务确实是一种异步服务）。订阅服务和互联网上RSS之类的订阅十分相似，服务调用者只需要订阅服务即可获得服务提供商推送的服务内容。大数据量上传服务事实上也是属于同步服务，然而由于消耗资源和性能压力不同，因此被单独作优化处理。关于服务形状不同，服务路由需要支持REST风格的服务路由和类REST风格服务的路由，但关于开发者来讲，调用的方式差不多上用服务名称来路由。正式环境和测试环境的隔离和切换关于服务开发者来讲，在应用开发期间需要有外部测试环境的支持，在商用以后需要有正式环境支持，同时两个环境的切换需要尽量的简单。服务集成平台支持服务提供商提供测试环境和正式环境的不同服务路由，同时两套环境切换成本低。当服务提供商只有一套环境的时候能够按照策略配置的不同，对调用者访咨询的范畴，频度，次数作限制，保证测试服务不阻碍正式服务。安全提供对应用身份认证以及服务提供商身份认证的支持，采纳多种数字签名算法实现差不多的身份认证，支持IP白名单和动态算法更新后端插件提供更高级别的服务安全保证。细化了用户授权流程。关于用户Token细分为要求级别和会话级别，同时关于会话级别的权限操作，失效时刻可按照服务提供商的配置自定义。同时平台托管爱护每个应用每个用户的多身份绑定Token，降低服务提供商开发爱护成本。服务提供商可配置服务访咨询量操纵和频率操纵（所有应用或者单个应用）。也支持配置需要订购才能够使用的服务（有限次数订购，无限次数订购）。支持多级服务安全策略配置，为服务配置（无授权，应用授权，用户授权，可选用户授权）等多种级别的安全策略。注：可选用户授权是指如果没有被用户授权的情形下使用接口将返回部分公布数据，而在用户授权情形下使用则返回全部的私有和公布数据。对服务提供商多级分类，提供不同的安全策略组合。监控与告警服务使用者服务使用出错监控和告警。服务提供商提供的服务可用性，超时状况的监控和告警。服务集成平台服务处理状况，内部模块运行状况监控和告警。日志采集与统计分析高并发下日志采集异步处理，采集服务正常访咨询和专门访咨询日志，采集用户绑定类，异步服务类，平台内部服务类等专门日志。每日，每周，每月访咨询日志统计分析，基础报表和趋势分析图的创建。支持分析结果预警配置。历史统计数据治理和归档。平台内置服务平台为服务提供商以及服务调用者提供了平台级别的服务，为开发商和服务提供者猎取平台业务数据以及运行期配置安全策略提供方便。平台提供一系列平台模块监控、配置、重置服务，支持在线咨询题查找、定位、解决的一套机制。非功能性需求（当前情形）性能：压力测试单机500并发用户1600+的tps，多机处理能力线性增长。模块化：内部处理模块化结构，支持运行期配置、装载、卸载。容错：服务集成平台核心数据都缓存在Memcache中，因此Memcache集群以及容错策略的扩展都为平台稳固和容错作了基础保证。配套支持通过ISV,ISP,Admin三个Portal，使开发者，服务提供商以及后台爱护人员能够自主爱护差不多信息和查看有关数据。为开发者提供社区，测试区的支持，同时提供开发工具包和文档，方便开发。扩展集成支持不同平台的服务集成。支持Google,Flickr,Yahoo等等不同的服务平台的服务集成，当前还没有完全将安全体系集成，只能够支持安全流程透传，消息数据完整过滤。服务集成平台的一些进展趋势数据集成和流程集成

当前专门多服务差不多上基础的数据型服务，使用者通过数据选择猎取相应的数据，然后展现给用户，这些服务的集成相对来讲功能比较单一，流程也不复杂。但随着服务提供商的进展，数据类型服务将会作为基础服务的一部分，而越来越多业务处理型服务会成为使用者的首选，现在，如何让服务和服务之间数据互通，服务能够通过一定的描述编排，就会变得越来越有价值，就如前面提到的，Google采纳GData作为数据规范格式，同时关于安全流程的统一制定，为第二时期的集成打下了基础。服务基础平台间的互通

最近OpenID也再次由于各大网站的支持而被人们广泛关注，在以后OpenAPI体系中，相伴着OpenID的进展，服务基础平台之间的服务互通也将会变得越来越容易，然而数据的安全性也会对每个服务平台要求更高。服务