CN102984132A - 用于网络应用接入的系统和方法 - Google Patents

Abstract

本发明公开了一种用于网络应用接入的系统和方法。该方法包括所述网络运营平台接收所述网络应用传送的应用程序接口API参数；所述网络运营平台根据预定的API生成标准，使用所述API参数生成适用于该网络应用的API定义；使所述网络应用基于所述网络运营平台生成的适用于该网络应用的API定义来构造自身API，所述网络运营平台通过所述网络应用构造的自身的API来访问所述网络应用；以及所述网络运营平台根据所接收的网络应用的API参数的参数值，呈现所述网络应用的API定义。本发明解决了现有技术中由网络应用来生成API时容易出错的问题，取得了能够由网络运营平台产生准确无误的API并提供给网络应用，因而有效避免了因API错误而导致网络应用接入错误的有益效果。

Description

用于网络应用接入的系统和方法

技术领域

本发明涉及通信领域，具体涉及一种将网络应用接入网络运营平台的用于网络应用接入的系统和相应的方法。

背景技术

随着网络的快速发展，出现了很多基于网络的应用。这些网络应用包括在线视频、在线交友以及网络游戏等。

以网络游戏为例，由于网络游戏使得参与游戏的人可以分布在各地并且一起协作，增加了传统局域网游戏和单机游戏所不具有的功能，因此正日益受到网络用户的欢迎。网络游戏又进一步包括网页游戏。在网页游戏领域，分工日益明显，一些公司负责开发网页游戏，一些公司负责运营网页游戏。网页游戏运营方作为网络运营平台，一般会同时运营多个公司开发的多款游戏。由于不同公司开发的游戏由不同的技术团队负责，甚至同一公司开发的多款游戏之间的技术团队也会有所不同，因此，如何将各个公司开发的每款游戏简便可靠而又快速地接入到网络运营平台上是一个亟待解决的问题。

目前，为了将各个公司开发的游戏接入到网络运营平台上，一般的做法是由网络运营平台提供一些技术规范，要求开发游戏的公司根据这些技术规范生成用于将游戏接入到网络运营平台的API。但是，采用这种方式，由开发游戏的公司生成API的过程中，由于对网络运营平台提供的技术规范理解不充分或者技术水平有限等原因，很可能导致生成的API是错误的，用错误的API接入网络运营平台时势必会错误百出，后续需要反复地进行修改、测试，由此开发游戏的公司以及网络运营平台双方都将浪费大量的时间。

发明内容

鉴于上述问题，提出了本发明以便提供一种将网络应用接入网络运营平台的用于网络应用接入的系统和相应的方法。

依据本发明的一个方面，提供了一种用于网络应用接入的系统，包括：网络运营平台以及网络应用，其中网络运营平台适于接收网络应用传送的应用程序接口API参数；根据预定的API生成标准，使用API参数生成适用于该网络应用的API定义；网络应用具有API，该API是基于网络运营平台生成的适用于该网络应用的API定义所构造而成；其中，网络运营平台通过所述网络应用的API来访问所述网络应用以及适于根据接收的所述网络应用的API参数的参数值，呈现所述网络应用的API定义，和/或验证与所述API定义相对应的API是否正确并显示验证结果。

依据本发明的另一方面，提供了一种将网络应用接入网络运营平台的用于网络应用接入的方法，包括步骤：网络运营平台接收网络应用传送的应用程序接口API参数；网络运营平台根据预定的API生成标准，使用API参数生成适用于该网络应用的API定义；以及使网络应用基于网络运营平台生成的适用于该网络应用的API定义来构造自身API，网络运营平台通过网络应用构造的自身的API来访问所述网络应用；以及所述网络运营平台根据所接收的网络应用的API参数的参数值，呈现所述网络应用的API定义。

根据本发明的用于网络应用接入的系统和方法，由网络运营平台预先设定API生成标准，并在接收到网络应用传送的API参数时根据API生成标准生成该网络应用的API定义，因此，网络应用无需自己生成API定义，只需根据网络运营平台生成的API定义来构造自身的API即可，由此解决了现有技术中由网络应用本身来生成API时容易出错的问题，取得了能够由网络运营平台产生准确无误的API定义并提供给网络应用，因而有效避免了因API错误而导致网络应用接入错误的有益效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的附图标记表示相同的部件。在附图中：

图1示出了根据本发明一个实施例的用于网络应用接入的系统的结构图；

图2示出了在本发明一个实施例中输入与网络应用相关联的API参数时的显示界面示意图；

图3示出了在本发明一个实施例中完全输入了与网络应用相关联的API参数后的显示界面示意图；

图4示出了在本发明一个实施例中在完全输入了与网络应用相关联的API参数后、进一步由网络运营平台对网络应用的API进行验证后的显示界面示意图；

图5示出了在本发明一个实施例中，系统管理员输入第一种验证指令后的显示界面示意图；

图6示出了在本发明一个实施例中，系统管理员输入第二种验证指令后的显示界面示意图；

图7示出了在本发明一个实施例中，系统管理员输入第三种验证指令后的显示界面示意图；以及

图8示出了根据本发明一个实施例的用于网络应用接入的方法的流程图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了本发明实施例提供的一种用于网络应用接入的系统的结构图。

如图1所示，该应用接入系统包括网络运营平台110以及一个或多个网络应用120。

网络运营平台110接收与网络应用120相关联的API参数，根据预定的API生成标准，使用该API参数，生成适用于该网络应用120的API定义，并将生成的适用于该网络应用120的API定义发送给该网络应用120。

该网络应用120在接收到网络运营平台110发来的适用于该网络应用120的API定义之后，基于该API定义来构造该网络应用120的API。网络应用120基于网络运营平台110发来的API定义来构造该网络应用120的API的含义是指：网络应用120构造与网络运营平台110发来的适用于该网络应用120的API定义相对应的网络应用功能，以便于网络运营平台110通过网络应用120的API来访问该网络应用120提供的功能。

也就是说，当网络运营平台110根据与网络应用120有关的API参数，并基于网络运营平台110上预定的API生成标准生成API定义之后，该API定义只是一个具有预定参数的URL链接地址，但是该URL链接地址并不会自动地与网络应用120关联起来。所以，这时网络运营平台110访问该URL地址是无法获取网络应用120所提供的功能的。因此，网络运营平台110需要将该API定义发送给网络应用120，由网络应用120构造与该API定义相对应的API，将网络应用所具有的网络应用功能与API相关联，使得网络运营平台110通过访问该API就可以达到访问网络应用120的相关功能的目的。

下面根据本发明的一个实施例，详细描述一下该应用接入系统的具体工作示例。

网络运营平台110上事先需要预先设置好API生成标准，该API生成标准预定义了根据API参数生成API定义的生成规则。

然后，网络运营平台110接收与网络应用120相关联的API参数，该API参数可以包括以下内容中的一项或多项：API的接口类型、区服信息、用户帐号、加密密钥和应用名称缩写。在向网络运营平台110输入与网络应用120相关联的API参数时的显示界面如图2所示。从图2中可以看到，所输入的与网络应用120相关联的API参数中包含API的接口类型。在接口类型中，除了图2所示的登录接口外，还可以是充值接口、查询接口等。另外API参数还可以包含游戏区服（如S1区服），以及用户qid（即用户帐号，图2中为116369412）。另外，网络应用120输入的API参数中还包含加密key（即加密密钥）、游戏缩写（如神仙道游戏的缩写为sxd）以及接口地址。在上述输入信息中，接口类型、游戏区服、用户帐号、游戏缩写等都是根据网络应用自身的特性来选择的，例如，以网络应用为神仙道游戏为例来说，其游戏缩写可以是sxd。另外，加密密钥中的值是网络应用120与网络运营平台110之间预先约定好的，接口地址可以是网络应用120接收网络运营平台110访问的URL地址。

在输入完上述API参数的值之后，点击“查看”就会生成适用于该网络应用120的API定义，这如图3所示。根据本发明的一个实施例，在网络运营平台110接收到图2中输入的各项API参数之后，可以根据预设的加密算法、基于预设的加密密钥对各个API参数进行加密，得到加密序列，并根据该加密序列生成API定义。因此，当API参数中包括API的接口类型、区服信息、用户帐号、加密密钥和应用名称缩写这几项信息时，生成的API定义中可以包含：API的接口类型、区服信息、用户帐号、加密序列和应用名称缩写。具体地，以图2和图3为例来说，API参数中包含的加密密钥是123456，假设预设的加密算法是md5算法，则可以通过如下代码来生成API定义：

在上述代码中，采用预设的加密算法，如md5算法，对预设的参数进行加密，得到加密序列sign。其中，md5算法中用到的参数包括“qid”（即API参数中的用户帐号）、“time”（即输入API参数时的系统时间）、“server_id”（即输入API参数的服务器地址）、以及“key”（即API参数中的加密密钥）。因此，加密序列sign是通过md5算法，以“key”作为加密密钥，对上述参数中的“qid”、“server_id”、“time”进行加密后得到的，由于上述参数中包含了输入API参数时的系统时间，而系统时间随每次输入API参数的时间而不同，所以，每次得到的加密序列sign都是不一样的，这提高了安全性。得到加密序列sign之后，即可根据加密序列生成url，该url中可以包含“qid”、“serber_id”、“time”参数以及上面得到的加密序列sign。网络运营平台110将该url作为适用于该网络应用120的API定义发送给网络应用120。网络应用120接收到该API之后的显示界面如图3所示，可以看出，在图3的“查看”按钮的下方显示出了由网络运营平台110生成的API定义，该API定义是一个具有预定参数的url地址。

网络应用120接收到图3中的API定义（即包括参数的URL）之后，为了确保万无一失，防止网络运营平台110生成的API定义在通信过程中被篡改，还可以进一步对网络运营平台110生成的API定义进行验证。在验证时，网络应用120可以根据预设的加密算法，基于预设的加密密钥对API定义中的API参数进行加密计算，得到加密序列；判断所计算得到的加密序列和所接收到的API定义中的加密序列是否相同，如果相同，说明API定义没有被篡改，是正确的，因而网络应用120构造与该API定义相对应的API，并将相应的网络应用功能与该API相关联，以便允许网络运营平台110通过该API调用该网络应用120的功能；否则，说明API定义被篡改了，是错误的，因而网络应用120不生成与该API定义相对应的API。依然以上述代码中的加密方式为例来说，网络应用120接收到的API定义中包含“qid”、“server_id”、“time”参数以及加密序列sign。因此，网络应用120直接利用md5算法，采用之前在图2的界面中输入的加密密钥对API定义中包含的“qid”、“server_id”、“time”参数进行加密，得到加密结果，当该加密结果与API定义中包含的sign值相等时，说明API定义是正确的，当该加密结果与API定义中包含的sign值不相等时，说明API定义是错误的。

通过上面的方式，可以由网络应用120对加密序列进行验证，以防止API定义被篡改，进而保证API定义的正确性。除了这种由网络应用120进行验证的方式之外，还可以由网络运营平台110对生成的API定义进行验证，以确保其正确性。

上述图3所示的界面不仅可以显示在网络应用120的管理员相应的客户端处，还可以同时显示在网络运营平台110的管理员相应的客户端处。因此，网络运营平台110还可以在接收到网络应用的API参数的参数值，并根据参数值计算出API定义之后，进一步呈现该网络应用的API定义，和/或验证该API定义是否正确并显示验证结果。具体地，网络运营平台110对API定义进行验证时可通过如下两种方式进行：

在第一种验证方式中，网络运营平台110通过网络应用120的API向网络应用120发送访问请求，根据网络应用120返回的响应消息来验证网络应用120的API是否正确，并将验证结果提供给网络应用120。具体地，网络运营平台110生成API定义，网络应用120根据该API定义构造自身的API，即构造与该API相应的网络应用功能。随后，网络运营平台110进一步用于通过该API向网络应用120发送访问请求，如果该API正确且网络应用120成功地构造了与该API相对应的网络应用功能，则网络应用120将通过该API接收到网络运营平台110发送的访问请求，然后，根据该访问请求向网络运营平台110返回响应消息，该响应消息可通过上述代码段中的Return函数实现。如果网络运营平台110接收到了网络应用120返回的响应消息，则说明该API已能够正常使用，因此，向网络应用120返回“成功”的验证结果，这如图4所示。如果网络运营平台110没有接收到网络应用120返回的响应消息，则说明该API还无法正常使用，因此，向网络应用120返回“失败”的验证结果。

在上述的第一种验证方式中，是直接在生成API定义之后自动地由网络运营平台110验证API的正确性。在第二种验证方式中，验证的时机与第一种方式不同，并不是一定在生成API定义之后就立即向网络应用120发请求验证，而是在后续的运行过程中的任何时候都可以验证。而且，第二种验证方式的具体操作方法也与第一种方式不同，第一种方式是通过预先定义的流程，在生成API定义之后自动地根据流程向网络应用120发请求验证，而第二种方式是由网络运营平台110的管理人员在需要验证API时，主动地输入一些指令，网络运营平台110根据预先设定的程序对管理人员输入的指令进行处理，并获取处理结果。

例如，采用第二种验证方式时，管理人员在指令输入框内输入“XXX.html?gkey=sxd”。该指令中的gkey表示游戏缩写，sxd表示“神仙道”游戏的缩写。管理人员输入该指令之后，在网络运营平台110上则会显示出“神仙道”游戏中所涉及的所有网络应用的API，例如，包含“登录接口”对应的API、“激活接口”对应的API、“兑换元宝接口”对应的API，以及“充值查询接口”对应的API等，如图5所示。采用该指令会将各个网络应用的API的具体url地址显示出来，以供管理人员查看或访问。另外，如果管理人员在指令输入框内输入“XXX.html?gkey=sxd&pay=1”，由于比上面介绍的指令增加了“pay=1”的参数，因此，除了显示“登录接口”、“激活接口”、“兑换元宝接口”，以及“充值查询接口”对应的API之外，还进一步访问“激活接口”和“兑换元宝接口”对应的API，根据返回结果来验证“激活接口”和“兑换元宝接口”对应的API是否正确，并将验证结果（如“成功”或“失败”）显示在对应API的后面，这如图6所示。进一步地，如果管理人员在指令输入框内输入“XXX.html?gkey=sxd&pay=1&new=1”，由于比上面介绍的指令进一步增加了“new=1”的参数，因此，除了显示“登录接口”、“激活接口”、“兑换元宝接口”，以及“充值查询接口”对应的API，并进一步访问“激活接口”和“兑换元宝接口”对应的API，根据返回结果来验证“激活接口”和“兑换元宝接口”对应的API是否正确之外，还会针对“充值查询接口”进行验证，并将充值查询结果直接显示出来，如图7所示。在图6和图7中，通过pay、new参数来控制是否对接口的API进行验证的具体过程可通过如下代码实现：

根据pay、new参数的值即可确定是否对API进行验证。

在第二种验证方式中，为了获取各个接口对应的API，可以在程序中设置一个GameDock类，在这个类中，为每个接口对应定义一个函数，例如，getLoginUrl函数用于获取“登录接口”的API，getPayDetailUrl函数用于获取“充值查询接口”对应的API，具体实现时可通过如下代码段实现：

通过上面的方式，即可验证API的正确性，以确保网络应用通过对应的API能够正确无误地接入网络运营平台。其中，第一种验证方式由于直接在API生成之后进行验证，验证及时且无需管理人员再执行额外的操作，所以验证方式简便易行。第二种验证方式通过输入预设的指令，可以根据指令同时对多个API进行验证，比起现有技术中常用的人工遍历各个API来逐个完成验证的方式相比，大大提高了验证效率，可同时完成多个API的验证。由此可见，网络运营平台110的上述两种验证方式各有其优点，可根据实际需要选择使用哪种验证方式。

通过本发明提供的应用接入系统，由于网络运营平台上预先设置了API生成标准，因此，可以由网络运营平台在接收到API参数后根据API生成标准来生成API定义，并由网络应用去实现与API定义相对应的API，而无需网络应用根据技术规范来编写API定义，从而既简化了网络应用的工作，提高了API的生成速度，也避免了网络应用在编写过程中因不理解技术规范而导致出错的可能性。另外，本发明提供的应用接入系统还提供了双重验证机制，一方面，网络应用在接收到API定义之后可根据加密算法进行验证，由此避免网络传输中出错的问题；另一方面，网络运营平台还可以采用两种方式对API进行验证，进一步确保了API的正确性，而且，由于网络运营平台可通过预设的程序执行验证过程，由此避免了人工验证时效率低下的问题。

本发明实施例中的应用接入系统可用于接入多种应用，除了上面描述的网络游戏之外，还可以接入其他的网络应用，例如，网络聊天、网络交友等等。

图8示出了本发明实施例提供的一种用于网络应用接入的方法的流程图。

如图8所示，该方法始于步骤S810，在步骤S810中，网络运营平台接收与网络应用相关联的API参数。

该API参数可以包括以下内容中的一项或多项：API的接口类型、区服信息、用户帐号、加密密钥和应用名称缩写。输入与网络应用相关联的API参数时的显示界面可参照图2。从图2中可以看到，所输入的与网络应用相关联的API参数包含API的接口类型。接口类型除了图2所示的登录接口外，还可以是充值接口、查询接口等。API参数还包含游戏区服（如S1区服）、以及用户qid（即用户帐号，图2中为116369412）。另外，API参数中还包含加密key（即加密密钥）、游戏缩写（如神仙道游戏的缩写为sxd）以及接口地址。在上述输入信息中，接口类型、游戏区服、用户帐号、游戏缩写等都是根据网络应用自身的特性来选择的，例如，以网络应用为神仙道游戏为例来说，其游戏缩写可以是sxd。另外，加密密钥中的值是网络应用与网络运营平台之间预先约定好的，接口地址可以是网络应用接收网络运营平台访问的URL地址。

通过步骤S810接收到与网络应用相关联的API参数后，在步骤S820中，网络运营平台根据预定的API生成标准，使用该API参数，生成适用于该网络应用的API定义，以及使网络应用基于网络运营平台生成的API定义来构造自身的API。

在网络运营平台接收到上述输入的各项API参数之后，可以根据预设的加密算法、基于预设的加密密钥对各个API参数进行加密，得到加密序列，根据该加密序列生成API定义。因此，当API参数中包括API的接口类型、区服信息、用户帐号、加密密钥和应用名称缩写这几项信息时，生成的API定义中可以包含：API的接口类型、区服信息、用户帐号、加密序列和应用名称缩写。具体地，API定义的生成方式可参照方法实施例中相应部分的描述，此处不再赘述。生成的API定义是一个具有预定参数的url，网络运营平台将该url作为适用于该网络应用的API定义发送给网络应用。

网络应用接收到网络运营平台发来的API定义之后，为了确保万无一失，防止网络运营平台生成的API定义在通信过程中被篡改，还可以进一步对网络运营平台生成的API定义进行验证。具体验证时，网络应用可以根据预设的加密算法，基于预设的加密密钥对其传送的API参数进行加密计算，得到加密序列；判断所计算得到的加密序列和所接收到的API定义中的加密序列是否相同，如果相同，说明API定义没有被篡改，是正确的，因而该网络应用基于网络运营平台发来的该API定义来构造网络应用自身的API（即：构造与该API相对应的网络应用功能），从而允许网络运营平台通过该API调用该网络应用的功能；否则，说明API定义被篡改了，是错误的，因而拒不构造相应的API。

另外，网络运营平台还可以在根据接收的网络应用的API参数的参数值，并根据参数值计算出API定义之后，进一步呈现该网络应用的API定义，和/或验证该API定义是否正确并显示验证结果。

而且，除了由网络应用对加密序列进行验证，以防止API定义被篡改，进而保证API定义的正确性之外，还可以由网络运营平台对生成的API定义进行验证，以确保其正确性。具体地，网络运营平台对API定义进行验证时可通过如下两种方式进行：

在第一种验证方式中，网络运营平台通过网络应用的API向网络应用发送访问请求，根据网络应用返回的响应消息来验证网络应用的API是否正确，并将验证结果提供给网络应用。具体地，网络运营平台生成API定义，网络应用根据该API定义构造自身的API，即构造与该API相应的网络应用功能。随后，网络运营平台进一步用于通过该API向网络应用发送访问请求，如果该API正确且网络应用成功地构造了与该API相对应的网络应用功能，则网络应用将通过该API接收到网络运营平台发送的访问请求，然后，根据该访问请求向网络运营平台返回响应消息，该响应消息可通过上述代码段中的Return函数实现。如果网络运营平台接收到了网络应用返回的响应消息，则说明该API已能够正常使用，因此，向网络应用返回“成功”的验证结果，如图4所示；如果网络运营平台没有接收到网络应用返回的响应消息，则说明该API还无法正常使用，因此，向网络应用返回“失败”的验证结果。

在上述的第一种验证方式中，是直接在生成API定义之后自动地由网络运营平台验证API的正确性。在第二种验证方式中，验证的时机与第一种方式不同，并不是一定在生成API定义之后就立即向网络应用发请求验证，而是在后续的运行过程中的任何时候都可以验证。而且，第二种验证方式的具体操作方法也与第一种方式不同，第一种方式是通过预先定义的流程，直接在生成API定义之后自动地根据流程向网络应用发请求验证，而第二种方式是由网络运营平台的管理人员在需要验证API时，主动地输入一些指令，网络运营平台根据预先设定的程序对管理人员输入的指令进行处理，并获取处理结果。

例如，采用第二种验证方式时，管理人员在指令输入框内输入“XXX.html?gkey=sxd”，其中，该指令中的gkey表示游戏缩写，sxd表示“神仙道”游戏的缩写。管理人员输入该指令之后，在网络运营平台上则会显示出“神仙道”游戏中所涉及的所有网络应用的API，例如，包含“登录接口”对应的API、“激活接口”对应的API、“兑换元宝接口”对应的API，以及“充值查询接口”对应的API等，如图5所示。采用该指令会将各个网络应用的API的具体url地址显示出来，以供管理人员查看或访问。另外，如果管理人员在指令输入框内输入“XXX.html?gkey=sxd&pay=1”，由于比上面介绍的指令增加了“pay=1”的参数，因此，除了显示“登录接口”、“激活接口”、“兑换元宝接口”，以及“充值查询接口”对应的API之外，还进一步访问“激活接口”和“兑换元宝接口”对应的API，根据返回结果来验证“激活接口”和“兑换元宝接口”对应的API是否正确，并将验证结果（如“成功”或“失败”）显示在对应API的后面，如图6所示。进一步地，如果管理人员在指令输入框内输入“XXX.html?gkey=sxd&pay=1&new=1”，由于比上面介绍的指令进一步增加了“new=1”的参数，因此，除了显示“登录接口”、“激活接口”、“兑换元宝接口”，以及“充值查询接口”对应的API，并进一步访问“激活接口”和“兑换元宝接口”对应的API，根据返回结果来验证“激活接口”和“兑换元宝接口”对应的API是否正确之外，还会针对“充值查询接口”进行验证，并将充值查询结果直接显示出来，如图7所示。

在第二种验证方式中，为了获取各个接口对应的API，可以在程序中设置一个GameDock类，在这个类中，为每个接口对应定义一个函数，例如，getLoginUrl函数用于获取“登录接口”的API，getPayDetailUrl函数用于获取“充值查询接口”对应的API。

通过上面的方式，即可验证API的正确性，以确保网络应用通过对应的API能够正确无误地接入网络运营平台。其中，第一种验证方式由于直接在API生成之后进行验证，验证及时且无需管理人员再执行额外的操作，所以验证方式简便易行。第二种验证方式通过输入预设的指令，可以根据指令同时对多个API进行验证，比起现有技术中常用的人工遍历各个API来逐个完成验证的方式相比，大大提高了验证效率，可同时完成多个API的验证。由此可见，网络运营平台的上述两种验证方式各有其优点，可根据实际需要选择使用哪种验证方式。

通过上面的方式生成API并确保API正确之后，在步骤S830中，网络运营平台就可以通过网络应用构造的自身的API来访问该网络应用了，由此实现网络应用可靠接入网络运营平台的目的。

另外，在上面的描述中，是以预定的API生成标准为加密算法为例进行描述的，实际情况中，也可以采用其它的生成标准，例如，不进行加密，只进行简单的数学运算等方式，也可以实现生成API的目的。

通过本发明提供的应用接入方法，由于网络运营平台上预先设置了API生成标准，因此，可以由网络运营平台在接收到API参数后根据API生成标准来生成API定义，无需网络应用根据技术规范来编写API，从而既简化了网络应用的工作，提高了API的生成速度，也避免了网络应用在编写过程中因不理解技术规范而导致出错的可能性。另外，本发明提供的系统还提供了双重验证机制，一方面，网络应用在接收到API定义之后可根据加密算法进行验证，由此避免网络传输中出错的问题；另一方面，网络运营平台还可以采用两种方式对API进行验证，进一步确保了API的正确性，而且，由于网络运营平台可通过预设的程序执行验证过程，由此避免了人工验证时效率低下的问题。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据本发明实施例的文件至宿主文件中的捆绑装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (12)

1.一种用于网络应用接入的系统，包括：网络运营平台以及网络应用，其中，

网络运营平台适于接收网络应用传送的应用程序接口API参数；根据预定的API生成标准，使用所述API参数生成适用于该网络应用的API定义；

所述网络应用具有API，该API是基于所述网络运营平台生成的适用于该网络应用的API定义所构造而成；

其中，所述网络运营平台通过所述网络应用的API来访问所述网络应用以及适于根据接收的所述网络应用的API参数的参数值，呈现所述网络应用的API定义，和/或验证与所述API定义相对应的API是否正确并显示验证结果。

2.如权利要求1所述的系统，所述网络运营平台适于通过所述网络应用的API向所述网络应用发送访问请求，根据所述网络应用返回的响应消息验证所述网络应用的API是否正确，并将验证结果提供给所述网络应用。

3.如权利要求1或2所述的系统，其中所述应用程序接口API为具有预定参数的URL。

4.如权利要求1-3中任一个所述的系统，其中，所述API的API参数包括：API的接口类型、区服信息、用户帐号、加密密钥和应用名称缩写。

5.如权利要求4所述的系统，所述网络运营平台适于根据预设的加密算法、基于预设的加密密钥对各个API参数进行加密，得到加密序列，且生成的API定义中包含：API的接口类型、区服信息、用户帐号、加密序列和应用名称缩写。

6.如权利要求5所述的系统，其中，所述网络应用在构造其API时，适于根据所述预设的加密算法，基于预设的加密密钥对来自网络运营平台的API定义中的API参数进行加密计算，得到加密序列；判断所计算得到的加密序列和所接收的API定义中的加密序列是否相同，如果相同，则构造所述API。

7.一种用于网络应用接入的方法，用于将网络应用接入网络运营平台，包括步骤：

所述网络运营平台接收所述网络应用传送的应用程序接口API参数；

所述网络运营平台根据预定的API生成标准，使用所述API参数生成适用于该网络应用的API定义；以及

使所述网络应用基于所述网络运营平台生成的适用于该网络应用的API定义来构造自身的API，

所述网络运营平台通过所述网络应用构造的自身的API来访问所述网络应用；

所述网络运营平台根据所接收的网络应用的API参数的参数值，呈现所述网络应用的API定义。

8.如权利要求7所述的方法，所述网络运营平台通过所述网络应用构造的自身API来访问所述网络应用的步骤包括步骤：

所述网络运营平台通过所述网络应用构造的自身API向所述网络应用发送访问请求；以及

根据所述网络应用返回的响应消息验证所述网络应用构造的自身的API是否正确，并将验证结果提供给所述网络应用。

9.如权利要求7或者8所述的方法，其中所述API定义为具有预定参数的URL链接地址，以及所述网络应用构造自身API为在该网络应用上实现所述URL链接。

10.如权利要求7-9中任一个所述的方法，其中，所述API的API参数包括：API的接口类型、区服信息、用户帐号、加密密钥和应用名称缩写。

11.如权利要求10所述的方法，所述使用所述API参数生成适用于该网络应用的API定义的步骤包括步骤：根据预设的加密算法、基于预设的加密密钥对各个API参数进行加密，得到加密序列，且生成的API定义中包含：API的接口类型、区服信息、用户帐号、加密序列和应用名称缩写。

12.如权利要求11所述的方法，其中使所述网络应用基于所述网络运营平台生成的适用于该网络应用的API定义来构造该网络应用自身的API包括：

根据所述预设的加密算法，基于预设的加密密钥对所接收到的API参数进行加密计算，得到加密序列；以及

判断所计算得到的加密序列和所接收的API定义中的加密序列是否相同，如果相同，则构造所述API。

Images