一种基于开放应用编程接口实现网络业务的方法、系统及装置

摘要

本申请公开了一种基于开放应用编程接口实现网络业务的方法、系统及装置，用于解决基于现有技术实现网络业务时，业务数据安全性低以及业务可控性差的问题。主要技术方案包括：接收第三方开发服务器根据用户的业务请求发送的对Open API的调用请求；确定调用请求中请求调用的Open API对应的互联网服务提供商ISP服务器，并将调用请求发送到确定的ISP服务器；接收ISP服务器根据调用请求返回的服务页面，并将服务页面发送到第三方开发服务器，由第三方开发服务器对该服务页面进行处理后发送给用户，该处理为将该服务页面封装在业务请求对应的页面中。根据该技术方案，提高了数据的安全性以及对业务的可控性。

说明书

技术领域

本申请涉及网络通信技术领域，尤其涉及一种基于开放应用编程接口实现 网络业务的方法、系统及装置。

背景技术

Open API(Open-Application Programming Interface，开放应用编程接口) 是SaaS(Software as a Service，软件即服务)模式下常见的一种应用接口，ISP (Internet Service Provider，互联网服务提供商)将其可提供的网站服务分别封 装成一系列的API，开放给第三方开发者，例如，ISV(Independent Software Vendor，独立软件供应商)，ISV可通过其ISV服务器使用相应的业务，该方 式称为开放网站的API，所开放的API称为Open API。

ISP对外提供Open API后，吸引了更多ISV基于ISV提供的Open API开 发更多的应用，从而使得ISV能够获得更多的流量与市场份额，并且，对于ISV 而言，ISV服务器也不需要庞大的硬件与技术投资就可以轻松快捷的使用符合 其要求的业务，从而减少了投资成本。因此，Open API作为互联网在线服务的 发展基础，已经成为越来越多互联网企业发展服务的选择，在网络业务中具有 很大的发展空间。

基于Open API的应用前景，各大国内外网站的ISP都推出了自己的Open API网站(即基于Open API实现网络业务的网站)。目前普遍使用的Open API 为基于REST接口形式的Open API，称之为REST API。基于REST API实现网络 业务时，通过Internet(因特网)采用HTTP GET的方式向业务实现服务器发送 REST服务，业务实现服务器采用POST的方式响应REST服务，其中，业务实 现服务器以XML、Jason等结构化数据作为返回结果响应REST服务。

上述基于REST API实现网络业务的方案存在很多方面的不足，首先，以结 构化数据形式作为返回结果，ISV获取数据比较容易，而一般业务实现服务器 提供的业务数据都不希望被用户以外的第三方即ISV获得，因此，基于上述方 式实现的网络业务，对于业务实现服务器而言，数据安全性低；并且，目前大 部分网络业务都包含复杂业务逻辑的操作，通常需要用户和服务端之间进行多 次交互操作，而以上实现网络业务的方法中，一个REST API只能实现用户和服 务端之间的单次交互，例如查询、更新数据等。因此，对于复杂网络业务，ISV 需要构建多个REST API才能实现一个完整的流程，这使得ISV需要解析多个 API调用间的业务逻辑，非常难于使用，而且不同的ISV解析能力存在偏差，使 得业务一致性很难得到保证，从而对于业务实现服务器而言，业务的可控性差。

综上所述，基于现有API实现的网络业务，无法保证业务数据的安全性， 并且业务可控性差。

发明内容

有鉴于此，本申请实施例提供一种基于开放应用编程接口实现网络业务的 方法、系统及装置，用于解决基于现有技术实现网络业务时，业务数据安全性 低以及业务可控性差的问题。

本申请实施例通过如下技术方案实现：

根据本申请实施例的一个方面，提供了一种基于开放应用编程接口实现网 络业务的方法，包括：

接收第三方开发服务器根据用户的业务请求发送的对开放应用编程接口 Open API的调用请求；

确定所述调用请求中请求调用的Open API对应的互联网服务提供商ISP 服务器，并将所述调用请求发送到确定的所述ISP服务器；

接收所述ISP服务器根据所述调用请求返回的服务页面，并

将所述服务页面发送到所述第三方开发服务器，由所述第三方开发服务器 对所述服务页面进行处理后发送给所述用户，所述处理为将所述服务页面封装 在所述业务请求对应的页面中。

根据本申请实施例的另一个方面，还提供了一种基于开放应用编程接口实 现网络业务的装置，包括：

第一接收单元，用于接收第三方开发服务器根据用户的业务请求发送的对 开放应用编程接口Open API的调用请求；

第一ISP调用单元，用于确定所述第一接收单元接收的调用请求中请求调 用的Open API对应的互联网服务提供商ISP服务器，并将所述调用请求发送 到所述ISP确定单元确定的所述ISP服务器；

第一调用结果反馈单元，用于接收所述ISP服务器根据所述第一ISP调用 单元发送的调用请求返回的服务页面，并将所述服务页面发送到所述第三方开 发服务器，由所述第三方开发服务器对所述服务页面进行处理后发送给所述用 户，所述处理为将所述服务页面封装在所述业务请求对应的页面中。

根据本申请实施例的另一个方面，还提供了一种基于开放应用编程接口实 现网络业务的系统，包括：

第三方开发服务器、业务实现服务器以及ISP服务器；其中，

第三方开发服务器，用于根据用户的业务请求向业务实现服务器发送对开 放应用编程接口Open API的调用请求；以及，接收所述业务实现服务器返回 的服务页面，并将所述服务页面封装在所述业务请求对应的页面中发送给所述 用户；

业务实现服务器，用于根据所述第三方开发服务器发送的调用请求，确定 所述调用请求中请求调用的Open API对应的互联网服务提供商ISP服务器， 并将所述调用请求发送到确定的所述ISP服务器；以及，接收所述ISP服务器 返回的服务页面，并将所述服务页面发送给所述第三方服务器；

ISP服务器，用于根据所述业务实现服务器发送的调用请求返回相应的服 务页面给所述业务实现服务器。

通过本申请实施例提供的上述至少一个技术方案，在实现网络业务时，首 先接收第三方开发服务器根据用户的业务请求发送的对Open API的调用请求， 确定该调用请求中请求调用的Open API对应的ISP服务器，并将该调用请求 发送到确定的ISP；进而接收该ISP根据调用请求返回的服务页面，并将该服 务页面发送至第三方开发服务器，由该第三方开发服务器对服务页面进行处理 后发送给用户，其中的处理为将服务页面封装在业务请求对应的页面中，根据 该技术方案，一方面，通过服务页面的形式将服务数据返回给第三方开发服务 器，与现有技术中直接将服务数据以结构化数据形式返回给第三方开发服务器 相比，提高了数据的安全性；另一方面，第三方服务器无需具备对业务逻辑分 析的功能，所有业务的控制都通过介于第三方服务器以及各ISP之间的服务器 实现，从而提高了对业务的可控性。

本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明 书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可 通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获 得。

附图说明

附图用来提供对本申请的进一步理解，并且构成说明书的一部分，与本申 请实施例一起用于解释本申请，并不构成对本申请的限制。在附图中：

图1为本申请实施例提供的基于Open API实现网络业务的方法流程图一；

图2为本申请实施例提供的将调用请求发送到ISP服务器的流程图；

图3为本申请实施例提供的触发的下一Open API的调用流程图一；

图4为本申请实施例提供的触发的下一Open API的调用流程图二；

图5为本申请实施例提供的实现网络业务涉及的系统交互示意图；

图6为本申请实施例提供的基于Open API实现网络业务的流程图二；

图7为本申请实施例提供的采用鉴权组件实现鉴权的流程图；

图8为本申请实施例提供的基于Open API实现网络业务的系统示意图；

图9为本申请实施例提供的基于Open API实现网络业务的装置示意图一；

图10为本申请实施例提供的第一ISP调用单元结构示意图一；

图11为本申请实施例提供的基于Open API实现网络业务的装置示意图 二；

图12为本申请实施例提供的基于Open API实现网络业务的装置示意图 三；

图13为本申请实施例提供的第二ISP调用单元以及第二调用结果反馈单 元的结构示意图；

图14为本申请实施例提供的基于Open API实现网络业务的装置示意图 四；

图15为本申请实施例提供的鉴权单元的结构示意图；

图16为本申请实施例提供的第一ISP调用单元结构示意图二。

具体实施方式

为了给出提高业务数据安全性以及提高业务可控性的实现方案，本申请实 施例提供了一种基于开放应用编程接口实现网络业务的方法、系统及装置，该 技术方案可以应用于网络业务的实现过程，既可以实现为一种方法，也可以实 现为一种装置。以下结合说明书附图对本申请的优选实施例进行说明，应当理 解，此处所描述的优选实施例仅用于说明和解释本申请，并不用于限定本申请。 并且在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

根据本申请实施例，首先提供了一种基于开放应用编程接口实现网络业务 的方法，如图1所示，该方法主要包括如下步骤：

步骤101、业务实现服务器接收第三方开发服务器根据用户的业务请求发 送的对Open API的调用请求。

步骤102、业务实现服务器确定接收的调用请求中请求调用的Open API 对应的ISP，并将该调用请求发送到确定的ISP服务器；

步骤103、业务实现服务器接收ISP服务器根据调用请求返回的服务页面。

步骤104、业务实现服务器将该服务页面发送到第三方开发服务器，由该 第三方开发服务器对服务页面进行处理后发送给用户。

该步骤104中，第三方开发服务器对服务页面进行的处理具体为：将该服 务页面封装在业务请求对应的页面中。

通过上述流程实现网络业务的方法，可以应用于多种网络环境下，其中的 业务实现服务器可以为设置在相应网络环境下的用于对该网络环境下实现的 业务进行控制和管理的服务器；其中的第三方开发服务器可以为独立软件供应 商ISV服务器。

本申请实施例中，若调用请求中请求调用的Open API为多个，则在将调 用请求发送到确定的ISP服务器之前，即在执行上述步骤102之前，还进一步 执行如下步骤：

确定多个Open API之间的调用关系。

该多个Open API之间的调用关系用于表征该多个Open API是否存在调用 顺序，根据本申请实施例，一个调用请求可以同时调用多个Open API，该多个 Open API可以包括存在调用顺序的Open API，也可以包括独立的Open API， 该独立的Open API与其他Open API不存在调用顺序。

相应地，在确定多个Open API之间的调用关系后，图1所示流程的步骤 102中，将调用请求发送到确定的ISP服务器，具体如图2所示，包括如下步 骤：

步骤201、根据多个Open API之间的调用关系确定多个Open API之间是 否存在调用顺序，若是，执行步骤202，若否，执行步骤203。

步骤202、将调用请求发送到存在调用关系的多个Open API中调用顺序为 第一位的Open API对应的ISP服务器，然后转至图1中的步骤103。

步骤203、将调用请求发送到多个Open API分别对应的ISP服务器，然后 转至图1中的步骤103。

本申请实施例中，在调用请求中请求调用的Open API为多个并且该多个 Open API之间存在调用顺序时，需要根据业务逻辑进行多次调用，直到调用顺 序为最后一位的Open API被调用。在根据调用顺序进行第一次调用后，在将 服务页面发送到第三方开发服务器之前，即在执行图1所示流程中的步骤104 之前，还可以进一步执行如下步骤：

将多个Open API之间的调用顺序封装在服务页面中。

通过上述步骤的执行，将Open API之间的调用顺序封装在返回给用户的 服务页面中，用户可以触发下一Open API的调用流程，具体处理过程如图3 所示，包括如下步骤：

步骤301、业务实现服务器接收用户根据服务页面中封装的调用顺序触发 的对当前调用的第一Open API之后的第二Open API的调用请求。

步骤302、将该调用请求发送到与第二Open API对应的ISP服务器。

步骤303、接收第二Open API对应的ISP服务器根据该调用请求返回的服 务页面。

步骤304、将该服务页面发送到第三方开发服务器，由第三方开发服务器 对该服务页面进行处理后发送给用户。

根据图3所示流程，业务实现服务器根据用户触发的下一Open API的调 用请求，实现对该调用请求的调用过程。根据本申请优选实施例，在用户触发 下一Open API的调用流程后，还可以支持不同Open API对应的ISP服务器之 间的互调用，例如，对于涉及多个ISP服务器交互的复杂业务，在调用第一 Open API对应的ISP服务器提供的业务后，还需要进一步调用第二Open API 对应的ISP服务器提供的业务，但该第二Open API对应的ISP服务器可能只 支持特定ISP服务器的访问，该特定ISP服务器一般为首次被调用的Open API 对应的ISP服务器，在该情况下，就需要通过第一Open API对应的ISP服务 器调用该第二Open API对应的ISP服务器，从而实现对第二Open API对应的 ISP服务器提供的业务的获取，具体地，业务实现服务器根据用户触发的下一 Open API的调用请求，实现对该调用请求的调用过程，还可以如图4所示，包 括如下步骤：

步骤401、业务实现服务器接收用户根据服务页面中封装的调用顺序触发 的对当前调用的第一Open API之后的第二Open API的调用请求。

步骤402、根据多个Open API之间的调用关系确定调用第二Open API是 否需要通过第一Open API，若是，执行步骤403步骤404，若否，执行步骤 405～步骤406。

该步骤402中，即第一Open API和第二Open API之间存在互调用关系， 第二Open API的调用需要通过第一Open API来完成。

步骤403、通过第一Open API对应的ISP服务器将该调用请求转发至第二 Open API对应的ISP服务器。

步骤404、接收第一Open API对应的ISP服务器返回的处理后的服务页面， 至此跳转至步骤407。

该步骤404中，该处理具体为：第一Open API对应的ISP服务器接收第 二Open API对应的ISP服务器返回的服务页面，并将接收的该服务页面封装 在自身的服务页面中进行返回。

步骤405、将该调用请求发送到与第二Open API对应的ISP服务器。

步骤406、接收第二Open API对应的ISP服务器根据该调用请求返回的服 务页面，至此跳转至步骤407。

步骤407、将该服务页面发送到第三方开发服务器，由第三方开发服务器 对该服务页面进行处理后发送给用户。

本申请实施例中，将ISP返回的服务页面封装在业务请求对应的页面中， 具体包括：

将该服务页面通过嵌入页面Iframe形式嵌入业务请求对应的页面中。

其中，以Iframe形式嵌入的页面为Iframe元素，可以理解为页面中浮动 的框架(FRAME)。frames集合提供对Iframe内容的访问权限，即在具体应用中， 可以使用frames集合读写Iframe内包含的元素。

Iframe也即Inner Frame(嵌入页面)，是一种在已有的Web页面中嵌入另 一个Web页面的技术，被嵌入的Web页面显示在要嵌入页面的Web页面中的 指定的框架位置，但对于用户而言，不能感觉出当前展示的页面是来自于两个 不同的Web页面，因此，本申请实施例利用Iframe的该特性，实现了ISP服 务的Web开放，保证了安全性，同时也保证了用户体验。

本申请优选实施例中，为了增加业务实现的安全性以及可控性，在确定调 用请求中请求调用的对应的互联网服务提供商ISP之前，即在执行图1所示流 程的步骤102之前，还可以进一步包括如下步骤：

对发送业务请求的用户进行鉴权，并在鉴权通过后执行步骤102。

具体地，对发送业务请求的用户进行鉴权，可以通过多种方式，例如，向 用户返回登录界面，该用户若为注册用户，则通过登录界面提示用户提交注册 时的账号以及密码信息，若该用户非注册用户，可通过登录界面提示用户先进 行注册，在注册信息验证通过后允许其登录。

实际的业务实现过程中，一般涉及多次用户与网络侧服务器的交互，为了 保证用户登录的有效性，本申请实施例在用户成功登录的基础上，进一步验证 该用户每次发送业务请求时更新的与该业务请求对应的用户登录标识是否有 效，若有效，则对该用户鉴权通过，否则拒绝该用户的业务请求。其中，用户 登录标识在该用户本次成功登录后创建。在具体业务实现过程中，可以通过如 下方式实现用户登录标识的创建及更新：

实际应用中，业务请求一般基于浏览器发送，在业务实现服务器验证用户 本次登录成功之后，向浏览器写入本次登录过程中产生的用户登录标识Cookie 和写入该Cookie的时间信息，用户再次访问时(如调用Open API)，在验证 Cookie是否有效的时候，除了验证用户ID的存在，还需要验证再次访问的时 间和上述写入的时间之间的间隔是否在设定时间间隔内，即每次调用Open API 时，业务实现服务器都会验证Cookie并在验证通过后刷新该Cookie。若用户 在长时间不调用Open API，则在下次调用时需要重新登录，以增加业务的安全 性。

本申请实施例中，若确定的调用请求中请求调用的Open API对应的ISP 服务器为多个，将调用请求发送到确定的ISP服务器，具体包括：

将该调用请求发送到确定的多个ISP中的任意一个ISP服务器。

具体地，将该调用请求发送到确定的多个ISP中的任意一个ISP服务器， 可以通过随机路由算法实现，即通过随机路由算法将调用请求随机发送到多个 ISP服务器中的一台。同时对ISP服务器做心跳检测，根据ISP的状态对随机 列表进行动态更新。例如，若检测到某ISP出现异常，则从随机列表中删除该 ISP，下次不会将调用请求随机发送到该服务器；若检测到该ISP恢复正常工 作，则从随机列表中增加该ISP，下次可能将调用请求随机发送到该服务器。

具体地，可以通过HTTP软负载从多个ISP服务器中确定出用于提供业务 的ISP。

HTTP软负载基于一个中间件ConfigServer(即业务实现服务器)来实现， 各ISP服务器向ConfigServer注册HTTP服务，ConfigServer的客户端根据 ConfigServer中的注册地址，随机连接ISP服务器，并发送HTTP请求。每个 ISP服务通过一个ServerSide对象，将自己的地址信息发布到ConfigServer，每 个客户端(ClientSide)通过一个ClientSide对象向ConfigServer订阅自己需要 的服务，ConfigServer会将所有可用服务的最新列表实时推送给ClientSide， ClientSide通过某种路由算法(也可以随机)选择一个服务地址进行调用。具 体地，发送到ConfigServer的地址列表可以通过字符串String表示。

本申请实施例中，ISP服务器返回的服务页面可以优选地包括如下两种形 式：

方式一、ISP服务器返回一服务页面，ISV将ISP返回的服务页面嵌入自 身提供的服务页面，最后返回给用户的结果页面以ISP APP(Application， 即开发者开发的应用软件)对应的域名显示，即将ISP APP的域名嵌入结果页 面返回给用户，用户能看到的域名为ISP APP的域名。

方式二、ISP服务器根据获得的页头页尾链接，渲染好服务页面返回给业 务实现服务器，最后返回给用户的结果页面以业务实现服务器对应的域名显 示。其中，ISP服务器根据获得的页头页尾链接是ISV的APP通过调用API 时传入的参数信息，渲染服务页面即将获得的参数信息生成为一个完整的页 面。

根据本申请实施例，能够满足不同的业务需要，例如，有些业务要求显示 给用户时必须以业务实现服务器域名显示，才能正常进行后续流程，比如退款 操作中需要用户输入密码，为了防止安全漏洞和后续纠纷，输入密码框必须显 示在业务实现服务器的域名对应的页面下，用户在确定域名显示无误后，才执 行输入密码操作，以防止密码被第三方窃取。

为了更好地理解本申请实施例提供的技术方案，下面以业务实现服务器控 制业务实现的具体实例对本申请的实施例进行说明。

如图5所示，为该实施例中实现网络业务涉及的系统交互示意图，主要涉 及的实体包括第三方开发服务器ISV、业务实现服务器、多个ISP(为表述方 便，图中画出了3个ISP)以及鉴权组件。其中：

ISV发起的调用请求中可以包括页面API调用(即调用存在调用关系的多 个Open API)以及Rest API调用(即调用与其他Open API不存在调用顺序的 Open API)；

业务实现服务器负责业务实现的安全和流量控制，如图5所示，业务实现 服务器作为ISV和ISP之间的一个连接器，负责将ISV调用Open API的请求 转发到相应ISP。一个API流程，包含多个与ISP交互的操作步骤，其中，既 可以含有页面交互的操作，也可以含有普通REST API操作。同样，一个ISP 在处理流程页面API时，还可以调用其它的ISP提供的服务，将其它ISP提供 的页面以Iframee形式嵌入到自身提供的页面中，再返回给业务实现服务器， 由业务实现服务器转发给ISV；

鉴权组件负责实现各种鉴权过程，例如，业务实现服务器对于ISV的鉴权， ISP对应业务实现服务器的鉴权等。

如图6所示，为基于Open API实现业务的一个具体实施例，其中，该业 务流程需要调用三次Open API，并且ISP1响应的第二步操作中，需要调用ISP2 的服务，具体包括如下步骤：

步骤601、用户向ISV发起业务请求。

该步骤中，用户发起的业务请求可以包括出价请求、申请退款等请求。用 户需要登录之后，才可以发起该业务请求。

步骤602、ISV通过APP发起对Open API的调用请求。

该步骤中，调用请求中包含调用API需要的参数及对这些参数做的签名信 息。

步骤603、业务实现服务器收到请求后验证用户登录信息以及Cookie，若 验证通过，继续后续流程，否则拦截用户请求(该过程未在图中标出)。

步骤604、业务实现服务器验证ISV访问权限，其中包括通过验证该ISV 是否有调用该API的权限及流量控制，若验证通过，继续后续流程，否则拒绝 调用请求(该过程未在图中标出)。

步骤605、业务实现服务器通过解析调用请求，确定支持该Open API的 ISP1，将调用请求转发到ISP1服务器。

步骤606、ISP1服务器收到调用请求后，验证业务实现服务器签名，如果 签名验证成功，则继续后续流程，否则返回错误信息(该过程未在图中标出)。

步骤607、ISP1服务器返回服务页面到业务实现服务器。

步骤608、业务实现服务器封装ISP1服务器返回的服务页面，再返回给ISV APP。

步骤609、ISV APP将返回的服务页面封装到自身提供的应用页面中，展 示给用户。

步骤610、用户点击返回的服务页面，发起该流程的第二步骤，该请求直 接被发送到业务实现服务器。

步骤611、业务实现服务器收到该请求后，对用户进行鉴权，鉴权通过后 继续后续流程，否则返回错误信息给用户(该过程未在图中标出)。

步骤612、业务实现服务器通过解析调用请求，将该请求转发给ISP1服务 器。

步骤613、ISP1服务器收到请求后，验证业务实现服务器签名，如果签名 验证成功，则继续后续流程，否则返回错误信息(该过程未在图中标出)。

步骤614、ISP1服务器通过解析该请求，确定需要调用ISP2提供的服务， 向ISP2服务器发起调用ISP2的请求。

步骤615、ISP2服务器通过鉴权组件验证用户身份，鉴权组件验证用户 cookie，验证通过，则将验证结果返回ISP2服务器，并进行后续流程；否则跳 转到用户登录页面，要求用户重新登录(该过程未在图中标出)。

步骤616、ISP2服务器响应该服务请求，向ISP1服务器返回服务页面。

步骤617、ISP1服务器将ISP2服务器返回的服务页面组装到自身提供的 页面中返回给业务实现服务器。

步骤618、业务实现服务器将ISP1服务器返回的服务页面封装转发给ISV APP。

步骤619、ISV APP将返回页面组装到自身提供的服务页面中展示给用户。

步骤620、用户点击返回的服务页面，发起该流程的第三步骤，该请求直 接被发送到业务实现服务器。

步骤621、业务实现服务器收到该请求后，对用户进行鉴权，鉴权通过后 继续后续流程，否则返回错误信息给用户(该过程未在图中标出)。

步骤622、业务实现服务器通过解析调用请求，将该请求转发给ISP1服务 器。

步骤623、ISP1服务器收到请求后，验证业务实现服务器签名，如果签名 验证成功，则继续后续流程，否则返回错误信息(该过程未在图中标出)。

步骤624、ISP1服务器将自身提供的服务页面返回给ISV APP。

步骤625、ISV APP根据ISP1服务器返回的结果信息，组装结果页面展示 给客户。

上述流程中，业务实现服务器起连接中转和控制监管作用，外部ISV发起 请求到业务实现服务器，业务实现服务器收到请求后验证该ISV是否有权限访 问该页面，如果有权限则发送请求到ISP，接受ISP签名验证，解析ISP返回 的数据，并返回给外部ISV。具体地，业务实现服务器和ISP之间可以采用HTTP 方式进行调用，即ISP提供HTTP服务，业务实现服务器通过HTTP客户端访 问ISP页面，即业务实现服务器通过HTTP客户端访问ISP的页面，ISP将页 面内容直接输出给业务实现服务器。实际应用中，业务实现服务器接收到Open API调用请求之后，会做以下判断：

浏览器中的Cookie是否有效；

Sign参数是否合法；其中的Sign参数用于验证ISV用户传入的数据，该 参数在ISV调用API前根据ISV与业务实现服务器约定算法生成，并在调用 API时传入；

Appkey参数是否合法，且是否具备当前页面API的访问权限；访问每个 API的应用都有一个唯一标识及密钥，称之为Appkey参数(包括Appkey和 APP Secret)，分别用来对每个应用做身份认证及安全控制，该参数在ISV调 用API时传入；

Session参数和Cookie中的用户是否对应；ISV开发的应用在获取业务实 现服务器提供的信息时，如果该信息为用户的私有信息，需要用户登录后才能 获取，该Session参数(即Session key)是用户登录后获取，用来表明该数据 经过用户授权可以获取，该信息在用户登录时产生，调用API时传入；

Timestamp参数和当前时间间隔是否在30分钟以内；其中的Timestamp 参数用于控制ISV应用访问API的次数，由业务实现服务器生成，并写入用户 浏览器Cookie，用户通过页面访问API时，读取cookie获取；

Session参数对应的用户是否具备访问对应appkey的权限；

如果上述规则任何一条不满足，则确定对用户鉴权不通过。

进一步地，上述流程中，鉴权组件提供了统一的登录验证功能，实际应用 中，该鉴权组件可以以独立服务器的形式存在，即采用与业务实现服务器的域 名、ISP的域名不同的域名。在业务实现服务器的域中写入Cookie，在其它ISP 鉴权时只要验证业务实现服务器的域中的Cookie是否存在，为了使其它域能 访问该业务实现服务器域中的Cookie，访问时可以使用P3P header实现。

采用鉴权组件实现鉴权的具体处理流程如图7所示，包括如下步骤：

步骤701、用户向ISV发送登录请求。

步骤702、ISV通过APP将该登录请求转发到业务实现服务器，同时将自 身鉴权参数传给业务实现服务器。

步骤703、业务实现服务器收到请求后，发送登录请求到鉴权组件。

步骤704、鉴权组件收到业务实现服务器的登录请求后，跳转到用户登录 页面，用户输入用户名和密码，验证成功，执行后续步骤，否则跳回登录页面 (该过程未在图中标出)。

步骤705、鉴权组件向业务实现服务器发起写Cookie请求。

步骤706、业务实现服务器收到请求后，根据请求参数做安全验证，验证 通过后，写入cookie。

步骤707、业务实现服务器将写入成功响应返回鉴权组件。

上述基于Open API实现网络业务的方法还可以实现为一种系统，如图8 所示，为本申请实施例提供的基于开放应用编程接口实现网络业务的系统对应 的网络拓扑图，其中包括：

第三方开发服务器801、业务实现服务器802以及ISP服务器803(实际 应用中，ISP服务器为多个，图8为了简化起见，仅示出了2个)。

业务实现服务器802用户对网络业务进行整体调度以及控制，具体地，各 服务器分别完成如下功能：

第三方开发服务器801，用于根据用户的业务请求向业务实现服务器802 发送对开放应用编程接口Open API的调用请求；以及，接收业务实现服务器 802返回的服务页面，并将该服务页面封装在业务请求对应的页面中发送给用 户；

业务实现服务器802，用于根据第三方开发服务器801发送的调用请求， 确定该调用请求中请求调用的Open API对应的互联网服务提供商ISP服务器 803，并将该调用请求发送到确定的ISP服务器803；以及，接收ISP服务器返 回的服务页面，并将该服务页面发送给第三方服务器801；

ISP服务器803，用于根据业务实现服务器802发送的调用请求返回相应 的服务页面给业务实现服务器802。

上述基于Open API实现网络业务的方法还可以实现为一种装置，如图9 所示，与上述方法流程对应，本申请实施例还提供了一种基于开放应用编程接 口实现网络业务的装置，该装置包括：

第一接收单元901、第一ISP调用单元902以及第一调用结果反馈单元903；

其中：

第一接收单元901，用于接收第三方开发服务器根据用户的业务请求发送 的对开放应用编程接口Open API的调用请求；

第一ISP调用单元902，用于确定第一接收单元901接收的调用请求中请 求调用的Open API对应的互联网服务提供商ISP服务器，并将所述调用请求 发送到所述ISP确定单元确定的所述ISP服务器；

第一调用结果反馈单元903，用于接收ISP服务器根据第一ISP调用单元 902发送的调用请求返回的服务页面，并将所述服务页面发送到第三方开发服 务器，由第三方开发服务器对所述服务页面进行处理后发送给所述用户，所述 处理为将所述服务页面封装在所述业务请求对应的页面中。

如图10所示，本申请优选实施例中，图9所示的第一ISP调用单元902 还可以具体包括：调用关系确定模块902A、第一调用执行模块902B以及第二 调用执行模块902C；其中：

调用关系确定模块902A，用于在第一接收单元901接收的调用请求中请 求调用的Open API为多个，确定该多个Open API之间的调用关系；

第一调用执行模块902B，用于在根据调用关系确定模块902A确定的调用 关系确定所述多个Open API之间存在调用顺序时，将所述调用请求发送到所 述多个Open API中调用顺序处于第一位的Open API对应的ISP服务器；

第二调用执行模块902C，用于在根据调用关系确定模块902A确定的调用 关系确定所述多个Open API之间不存在调用顺序时，将所述调用请求发送到 所述多个Open API分别对应的ISP服务器。

如图11所示，本申请优选实施例中，图9所示的装置，还可以进一步包 括：

调用关系封装单元904，用于在根据调用关系确定所述多个Open API之间 存在调用顺序时，将所述多个Open API之间的调用顺序封装在所述服务页面 中，并将封装处理后的服务页面提供给所述第一调用结果反馈单元903。

如图12所示，本申请优选实施例中，图9所示的装置还可以进一步包括：

第二接收单元905、第二ISP调用单元906以及第二调用结果反馈单元907；

其中：

第二接收单元905，用于接收所述用户根据第一调用结果反馈单元903返 回的服务页面中封装的所述调用顺序触发的对当前调用的第一Open API之后 的第二Open API的调用请求；

第二ISP调用单元906，用于将第二接收单元905调用请求发送到与所述 第二Open API对应的ISP服务器；

第二调用结果反馈单元907，用于接收所述第二Open API对应的ISP服务 器根据第二ISP调用单元906发送的调用请求返回的服务页面，并将所述服务 页面发送到第三方开发服务器，由第三方开发服务器对所述服务页面进行处理 后发送给所述用户。

如图13所示，本申请优选实施例中，图12所示装置包括的第二ISP调用 单元906，具体包括：

调用关系解析模块906A，用于在将第二接收单元905接收的调用请求发 送到与所述第二Open API对应的ISP服务器之前，根据所述多个Open API之 间的调用关系确定所述第二Open API是否需要通过所述第一Open API调用所 述第二Open API；

调用请求发送模块906B，用于在调用关系解析模块906A的确定结果为是 时，通过所述第一Open API对应的ISP服务器将所述调用请求转发至所述第 二Open API对应的ISP服务器；

相应地，该实施例中，图12所示装置包括的第二调用结果反馈单元907， 具体包括：

接收模块907A，用于接收所述第一Open API对应的ISP服务器返回的处 理后的服务页面，其中，所述服务页面时所述第一Open API对应的ISP服务 器接收所述第二Open API对应的ISP服务器返回的服务页面，并将接收的该 服务页面封装在自身提供的服务页面中返回的；

反馈模块907B，用于将接收模块907A接收的服务页面发送到所述第三方 开发服务器，由所述第三方开发服务器对所述服务页面进行处理后发送给所述 用户。

如图14所示，本申请优选实施例中，图9所示的装置还可以进一步包括：

鉴权单元908，用于对发送所述业务请求的用户鉴权，并在确定对所述用 户鉴权通过后，指示第一ISP调用单元902确定所述调用请求中请求调用的 Open API对应的互联网服务提供商ISP服务器。

如图15所示，本申请优选实施例中，图14所示装置包括的鉴权单元908 可以进一步包括：

鉴权模块908A，用于在确定所述用户满足设定条件时确定对所述用户鉴 权通过：其中，所述设定条件包括：

在所述用户成功登录时，创建用户登录标识；并

确定在所述用户每次发送业务请求时更新的所述用户的用户登录标识为 有效；

指示模块908B，用于在鉴权模块908A鉴权通过后，指示第一ISP调用单 元902确定所述调用请求中请求调用的Open API对应的互联网服务提供商ISP 服务器。

如图16所示，本申请优选实施例中，图9所示装置包括的第一ISP调用 单元902，还可以进一步包括：

ISP服务器确定模块902D，用于确定所述调用请求中请求调用的Open API 对应的ISP个数；

ISP服务器选择模块902E，用于当所述ISP服务器确定模块902D确定的 ISP为多个时，采用随机路由算法在确定的所述多个ISP中定位一个ISP服务 器，并将所述调用请求发送到定位到的ISP服务器。

本申请的实施例所提供的基于开放应用编程接口实现网络业务的装置所 实现功能的具体方式或/和手段在上述方式实施例中的相应处理步骤中已详细 说明，在此不再赘述。

本申请实施例提供的基于开放应用编程接口实现网络业务的装置，可以作 为单独的装置存在。在实际应用中，考虑到网络结构的简化，可以将该装置实 现的功能集成在业务实现服务器中，例如，在业务实现服务器中增加该装置为 实现上述功能对应的单元。并且本申请的实施例所提供的基于开放应用编程接 口实现网络业务的装置可通过计算机程序实现。本领域技术人员应该能够理 解，上述的模块划分方式仅是众多模块划分方式中的一种，如果划分为其他模 块或不划分模块，只要该装置具有上述功能，都应该在本申请的保护范围之内。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产 品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和 /或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/ 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入 式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算 机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一 个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设 备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中 的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个 流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使 得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处 理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个 流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

通过本申请实施例提供的上述至少一个技术方案，在实现网络业务时，首 先接收第三方开发服务器根据用户的业务请求发送的对Open API的调用请求， 确定该调用请求中请求调用的Open API对应的ISP，并将该调用请求发送到确 定的ISP；进而接收该ISP根据调用请求返回的服务页面，并将该服务页面发 送到第三方开发服务器，由该第三方开发服务器对服务页面进行处理后发送给 用户，其中的处理为将服务页面封装在业务请求对应的页面中，根据该技术方 案，一方面，通过服务页面的形式将服务数据返回给第三方开发服务器，与现 有技术中直接将服务数据以结构化数据形式返回给第三方开发服务器相比，提 高了数据的安全性；另一方面，第三方服务器无需具备对业务逻辑分析的功能， 所有业务的控制都通过介于第三方服务器以及各ISP之间的服务器实现，从而 提高了对业务的可控性。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申 请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及 其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。