CN103051623B - 限制开放平台的调用的方法 - Google Patents

Abstract

本发明公开了一种限制开放平台的调用的方法，包括：接收应用发出的开放平台调用消息，从该消息中解析出应用的IP地址，应用的APPKEY，应用需要操作的业务类型和需要调用的用户数据所属的用户的UID；当根据应用的APPKEY和应用的IP地址，确定该应用在第一时间段内对开放平台的IP调用次数小于IP维度限制次数，并且根据用户的UID、应用的APPKEY以及应用要操作的业务类型，确定在第二时间段内该应用对用户数据的用户调用次数小于业务总限制次数，每一种业务类型调用次数小于相应的业务类型限制次数时，允许该应用调用开放平台。由于从应用在IP维度和用户维度对调用开放平台的进行限制，增强了应用对开放平台的调用的安全性和稳定性。

Description

限制开放平台的调用的方法

技术领域

本发明涉及计算机技术，尤其涉及一种限制对开放平台的调用的方法。

背景技术

在计算机软件和计算机网络中，开放平台（OpenPlatform）是指软件系统通过公开其应用程序编程接口（API）或函数（function）来使外部程序可以增加该软件系统的功能或使用该软件系统的资源，而不需要更改该软件系统的源代码。随着开放平台的兴起和日益壮大，越来越多的开发者在开放平台的基础上，参与到应用的开发中来。例如，近年来全球对于微博的需求也来越多。许多互联网公司也针对微博技术提供了功能健全的微博开放平台。第三方开发者，可以通过调用微博的开放平台，开发自己的各种应用。各种各样的应用，每天都在调用开放平台来实现自己的功能。而越来越大的对开放平台的调用量，成为了开放平台不得不考虑的现实问题。控制对开放平台的调用频率成为了摆在开放平台开发人员面前的首要问题。

在计算机软件和计算机网络技术中，对于开放平台的调用涉及到应用、用户和开放平台三方。应用指的是由第三方开发者开发的接入开放平台的应用程序。用户指的是资源的所有者，也就是应用所要获取信息的对象。运行应用的客户端所在的IP地址称为应用的IP地址。

在现有技术中，也对应用对开放平台的调用频率进行了限制。然而，现有技术中对开放平台的调用频率的限制在维度上仅仅是单一的IP限制，或是单一的用户限制。在应用对开放平台的调用频率的总限制次数上，也只是进行了粗粒度的限制。在对应用的限制级别和分类上面，没有进行细化的考虑。

可见，现有技术中，应用对开放平台的调用存在一定的安全性和稳定性隐患。因此，现有技术存在对一种能够增强对开放平台的调用的安全性和稳定性的技术的需要，该技术能够增强应用在对开放平台的调用时的规范性，限制对开放平台的调用频率，增强开放平台的安全性和稳定性。

发明内容

本发明的实施例提供一种限制开放平台的调用的方法，包括：接收应用发出的开放平台调用消息；从接收到的开放平台调用消息中解析出应用所在的客户端的IP地址，应用的应用标识APPKEY，应用需要操作的业务类型和需要调用的用户数据所属的用户的用户标识UID；根据应用的APPKEY和应用所在的客户端的IP地址，确定该应用在预先设置的第一时间段内对开放平台的IP调用次数是否小于IP维度限制次数；根据所述用户的UID、应用的APPKEY以及应用要操作的业务类型，确定在预先设置的第二时间段内该应用对所述用户数据的用户调用次数是否小于业务总限制次数，要操作的业务类型的业务类型调用次数是否小于相应的业务类型限制次数；如果所述IP调用次数小于IP维度限制次数，所述用户调用次数小于相应的业务限制次数，并且要操作的业务类型的业务类型调用次数小于该业务类型限制次数，允许该应用调用开放平台。

进一步，所述方法还包括步骤：将该IP地址的应用的IP调用次数加1，将该应用的用户调用次数加1，并且将该应用的要操作的每一种业务类型的业务类型调用次数加1，然后将IP调用次数、用户调用次数和要执行的业务类型的业务类型调用次数存储在缓存中。

其中，根据应用的APPKEY和应用所在的客户端的IP地址，确定该应用在第一时间段内对开放平台的IP调用次数是否小于IP维度限制次数包括：根据应用的APPKEY从数据库中获取应用的应用等级，并且根据应用的IP地址和应用等级从数据库中获取该应用等级的应用的IP维度限制次数；从缓存中读取该应用的IP调用次数，将所述应用的IP调用次数与IP维度限制次数进行比较以确定在IP维度是否允许应用调用开放平台。

其中，从缓存中读取该应用的IP调用次数，将所述应用的IP调用次数与IP维度限制次数进行比较以确定在IP维度是否允许应用调用开放平台包括：

如没有读取到该应用的IP调用次数，将该应用的IP调用次数设为0，并启动第一计时器，在IP维度允许应用调用开放平台；

如果从缓存中读取到IP调用次数，获取第一计时器的计时值并将第一计时器的计时值与第一时间段进行比较；

如果第一计时器的计时值小于第一时间段，将IP调用次数与IP维度限制次数进行比较，仅当确定IP调用次数小于IP维度限制次数时在IP维度允许应用调用开放平台；

如果第一计时器的计时值不小于第一时间段值，使第一计时器复位并重新开始计时，将IP调用次数设为0，在IP维度允许应用调用开放平台。

其中，根据所述用户的UID、应用的APPKEY以及应用要操作的业务类型，确定在第二时间段内该应用对所述用户数据的用户调用次数是否小于业务总限制次数，要操作的业务类型的业务类型调用次数是否小于相应的业务类型限制次数包括：

根据应用的APPKEY从数据库中获取应用的应用等级，并根据应用需要调用的用户数据所属的用户的UID和应用的应用等级从数据库中获取该应用等级的应用对用户的用户数据的业务总限制次数和每一种业务操作类型的业务类型限制次数；

从缓存中读取该应用的用户调用次数，将所述应用的用户调用次数与业务总限制次数进行比较以确定在用户维度是否允许应用调用开放平台。

其中，从缓存中读取该应用的用户调用次数，将所述应用的用户调用次数与业务总限制次数进行比较以确定在用户维度是否允许应用调用开放平台包括：

如没有从缓存中读取到用户调用次数，将用户调用次数设为0，将每一种业务类型的业务类型调用次数设为0，并启动第二计时器，在用户维度允许应用调用开放平台；

如从缓存中读取到用户调用次数，获取第二计时器的计时值并将第二计时器的计时值与第二时间段进行比较；

如果第二计时器的计时值小于第二时间段，则将用户调用次数与业务总限制次数进行比较，将存储在缓存中的每一种业务类型的业务类型调用次数与相应的业务类型限制次数比较，仅当确定用户调用次数小于业务总限制次数，并且每一种业务类型的业务类型调用次数小于相应的业务类型限制次数时在用户维度允许应用调用开放平台；

如果第二计时器的计时值不小于第二时间段值，使第二计时器复位并重新开始计时，将用户调用次数设为0，并将每一种业务类型的业务类型调用次数设为0，在用户维度允许应用调用开放平台。

其中，将存储在缓存中的每一种业务类型的业务类型调用次数与相应的业务类型限制次数比较包括：

将缓存中存储的第一业务类型的业务类型调用次数与第一业务类型的业务类型限制次数比较；

将缓存中存储的第二业务类型的业务类型调用次数与第二业务类型的业务类型限制次数比较；

将缓存中存储的第三业务类型的业务类型调用次数与第三业务类型的业务类型限制次数比较。

其中，将缓存中存储的第三业务类型的业务类型调用次数与第三业务类型的业务类型限制次数比较包括：

将第三业务类型的在第二时间段内的业务调用次数与第三业务类型在第二时间段内的第三业务限制次数比较；

将第三业务类型的在一天时间内的业务调用次数与第三业务类型在一天时间内的业务限制次数比较。

其中，第一至第三业务类型分别为发微博、发评论和加关注。

其中，所述应用标识APPKEY是应用向开放平台注册时由开放平台分配的唯一的应用标识，所述用户标识UID是在用户向注册时为用户分配的唯一的用户标识。

其中，应用的应用等级、IP限制次数、业务总限制次数和每一种业务操作类型的业务类型限制次数是由开放平台预先设置的。

由上述技术方案可见，本发明实施例提供的限制开放平台的调用的方法，在应用调用开放平台时，不仅根据应用的应用等级，从IP维度方面确定是否允许应用调用开放平台，还根据应用的应用等级，从用户维度方面确定是否允许应用调用开平台。特别地，根据应用的应用等级，确定在第一时间段内该应用的IP调用次数是否小于IP限制次数，如果IP调用次数小于IP限制次数则在IP维度允许应用调用开放平台；根据应用的应用等级和用户的UID，确定在第二时间段内该应用的用户调用次数是否小于业务总限制次数，应用的每一种业务类型的业务类型调用次数是否小于相应的业务类型限制次数，如果在第二时间段内该应用的用户调用次数小于业务总限制次数，并且应用的每一种业务类型的业务类型调用次数小于相应的业务类型限制次数，则在用户维度允许应用调用开放平台。只有在IP维度和用户维度都允许应用调用开放平台，应用才可以调用开放平台。因此，本发明能够增强应用对开放平台的调用的安全性和稳定性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，以下将对实施例或现有技术描述中所需要使用的附图作简单地介绍。显而易见地，以下描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员而言，还可以根据这些附图所示实施例得到其它的实施例及其附图。

图1示出了限制应用调用开放平台接口的系统结构示意图。

图2示出了限制应用调用开放平台的方法流程图。

图3示出了根据本发明的实施例的在IP维度确定是否允许应用调用开放平台的具体过程。

图4示出了根据本发明的实施例的在用户维度确定是否允许应用调用开放平台的具体过程。

具体实施方式

以下将结合附图对本发明各实施例的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。

如前所述，在涉及开放平台的技术中，涉及到三个角色，即应用，用户和IP。本发明中，根据开放平台的特殊性，综合考虑IP、应用和用户多个维度来对在预定时间段内调用开放平台的次数进行限制。

在应用或者应用程序使用开放平台之前，首先需要将应用向开放平台所在的服务器进行注册，以获得开放平台所在的服务器的授权。在接收到来自应用的注册请求之后，设置有开放平台的服务器将对应用进行授权。针对具体的应用，服务器可以为应用配置的授权分为测试授权，普通授权，中级授权，高级授权，合作授权。如果一个应用是在开发中的未通过审核的应用，服务器将给该应用分配测试授权。未通过审核的应用，对于其调用开放平台接口的限制会比较严格。如果一个应用是通过审核的应用，服务器可以根据该应用的具体需求，为该应用分配普通授权，中级授权，高级授权或者合作授权。一般地，通过审核的应用会自动升级为普通授权，即该应用至少获得普通授权。中级授权，高级授权和合作授权需要特别的申请才能够获得。

图1示出了限制应用调用开放平台接口的系统结构示意图。如图1所示，配置有应用12的客户端10通过网络连接到配置有开放平台22的服务器20。可以由多个客户端10，每一个客户端10上配置有相应的应用12。数据库30用于存放用户的数据。数据库可以位于服务器20中，也可以单独存在。如果服务器20与数据库30分离设置，则服务器20与数据库30通过网络连接。在网络中，应用所在的客户端10具有唯一的IP地址。配置有开放平台22的服务器称为服务系统。用户可以向服务系统进行注册。下文中，为便于说明，以开放平台22为微博开放平台为例来描述本发明。用户如果想使用服务系统即微博系统，其需要向微波系统进行注册。当用户向开放平台所在的微博系统进行注册时，微博系统为用户分配唯一的用户标识，即用户ID（简写为UID）。第三方开发者的应用12如果想要调用服务器20（微波系统）上的用户数据，第三方开发者首先需要将应用12向开放平台22进行注册。第三方开发者将应用12向开放平台22进行注册时，开放平台22将分配给该应用一个唯一的应用标识APPKEY，并如前所述对应用进行授权。在注册之后，应用12通过网络调用开放平台22，可以使用开放平台22的功能以及获取用户的数据。进行注册之后，用户或者应用每一次在微博开放平台上进行的发微博、发评论、加关注等的操作所产生的数据以及用户或应用的相关信息都会存储在数据库30中。开放平台22中还具有至少第一计时器和第二计时器。第一计时器用于根据第一时间段进行计时，第二计时器用于根据第二时间段进行定时。

本发明中，为了增强对开放平台的调用的安全性和稳定性，从应用在IP维度和用户维度对调用开放平台的进行限制。具体地，针对应用获得的各个授权级别，对应用所在的服务器的IP维度进行了约束，即对位于该IP地址的应用在第一时间段内对开放平台的调用次数设置一个相应的阈值；而且，针对应用的各个授权级别，对于一个应用调用一个用户数据的维度进行限制，即对一个应用在第一时间段内调用一个用户的数据的次数也设置相应的阈值。当应用调用开放平台时，其对开放平台的调用不能超过与该应用的应用等级相应的阈值。

本发明中，对于一个要调用开放平台的应用的情形定义为IP维度。在第一时间段内，允许来自一个IP地址的一应用等级的应用调用开放平台的最大次数称为IP维度限制次数。显然，对于来自一个IP地址的应用，应用等级不同，其IP维度限制次数不同。IP维度限制次数由开放平台预先设置并存储在数据库30中。

作为一个示例，假定第一时间段为1小时，在IP维度的具体限制为：

对于测试授权的应用，其调用开放平台的限制次数为：1000次/小时；

对于普通授权的应用，其调用开放平台的限制次数为：10000次/小时；

对于中级授权的应用，其调用开放平台的限制次数为：20000次/小时；

对于高级授权的应用，其调用开放平台的限制次数为：30000次/小时；

对于合作授权的应用，其调用开放平台的限制次数为：40000次/小时。

本发明中，对于一个应用要调用开放平台以获得开放平台的一个用户的用户数据的情形定义为用户维度。通过一个应用可进行多种业务类型的操作，该应用的每一种业务类型的操作都会涉及到调用开放平台以获得一个用户的用户数据。通常，在多种业务类型中，只有几种业务类型的操作会频繁发生，从而显著地影响调用开放平台的频率或次数。本发明中，对于每一种应用，不论其授权级别如何，对于显著地影响调用开放平台的频率或次数的第一业务类型至第三业务类型，还需分别设置调用开放平台的业务类型限制次数。即，针对第一业务类型至第三业务类型分别设置第一业务类型限制次数，第二业务类型限制次数和第三业务类型限制次数。对于示例性的微博开放平台而言，第一业务类型为发微博，第二业务类型为发评论，第三业务类型为加关注；相应地，第一至第三业务类型限制次数分别为发微博限制次数、发评论限制次数和加关注限制次数。对于其他的开放平台，可以根据具体的业务类型选取显著影响调用开放平台的业务类型并设定相应的业务类型限制次数。

用户维度的限制为：对于每一应用等级的应用，在第二时间段内，允许该应用调用开放平台的最大次数称为用户维度限制次数。对于微博系统，用户维度限制次数包括业务总限制次数，发微博限制次数，发评论限制次数和加关注限制次数。用户维度限制次数由开放平台预先设置并存储在数据库30中。

作为一个实例，对于微博系统而言，假设第二时间段为1小时，用户维度的具体限制为：

对于测试授权的应用，其调用开放平台的一个用户的用户数据的限制次数为：

业务总限制次数：单用户每应用150次/小时；

发微博限制次数：单用户每应用30次/小时

发评论限制次数：单用户每应用60次/小时

加关注限制次数：单用户每小时60次/小时，100次/天。

对于普通授权的应用，其调用开放平台的一个用户的用户数据的限制次数为：

业务总限制次数：单用户每应用1000次/小时；

发微博限制次数：单用户每小时30次/小时；

发评论限制次数：单用户每小时60次/小时；

加关注限制次数：单用户每小时60次/小时，200次/天。

对于中级授权的应用，其调用开放平台的一个用户的用户数据的限制次数为：

业务总限制次数：单用户每应用1500次/小时；

发微博限制次数：单用户每应用60次/小时；

发评论限制次数：单用户每应用120次/小时；

加关注限制次数：单用户每应用120次/小时，300次/天。

对于高级授权的应用，其调用开放平台的一个用户的用户数据的限制次数为：

业务总限制次数：单用户每应用2000次/小时；

发微博限制次数：单用户每应用90次/小时；

发评论限制次数：单用户每应用180次/小时；

加关注限制次数：单用户每应用180次/小时，300次/天。

对于合作授权的应用，其调用开放平台的一个用户的用户数据的限制次数为：

业务总限制次数：单用户每应用无限制；

发微博限制次数：单用户每应用120次/小时；

发评论限制次数：单用户每应用240次/小时；

加关注限制次数：单用户每应用240次/小时，300次/天。

显然，本发明中，上述应用调用开放平台的具体限制次数仅仅是示例性的，本领域技术人员可以根据实际需要配置不同的限制次数。第一时间段和第二时间段由开放平台22预先设置并存储在数据库中，二者可以相同也可以不同。

此外，对于微博系统，加关注限制次数包括：在第二时间段内的业务调用限制次数和一天时间内的业务类型限制次数。

本发明中，对于微博开放平台，当应用需要调用微博开放平台时，一方面需要根据应用的授权级别以及应用所在的服务器的IP地址，获知来自该IP地址的应用可以调用开放平台的限制次数，将来自该IP地址的应用已调用开放平台的实际次数与该IP地址的应用可以调用开放平台的限制次数相比以确定是否可以继续调用开放平台。另一方面，还需要根据应用的应用等级以及应用所调用的用户数据所属的用户的UID，确定该应用可以调用开放平台的用户数据的总限制次数和各种业务类型限制次数，将该应用已调用开放平台的实际次数与业务总限制次数相比以及将应用的各种业务类型调用次数与相应的业务类型限制次数相比以确定是否可以继续调用开放平台。如果上述两个条件任意之一不满足，则该应用不可以调用微博开放平台。

开放平台22预先划分应用的应用等级，并且为每一等级的应用预设第一时间段、IP维度限制次数以及用户维度限制次数的具体数值并存储在数据库30中。

图2示出了限制应用调用开放平台的方法流程图。如前所述，存在许多个应用，每一个应用都可以通过网络连接调用开放平台。任何一个应用都可以多次调用开放平台。如图2所示，在步骤210，如果一个应用需要调用开放平台22，该应用首先向开放平台发出开放平台调用消息。开放平台调用消息中封装有应用所在的客户端的IP地址，应用的APPKEY，应用需要操作的业务类型和需要调用的用户数据所属的用户的UID。在步骤220，服务器20从接收到的开放平台调用消息中解析出应用所在的客户端的IP地址，应用的APPKEY，应用需要操作的业务类型和需要调用的用户数据所属的用户的UID。接下来，根据应用的APPKEY和应用所在的客户端的IP地址，确定该IP地址的应用在预先设置的第一时间段内对开放平台的已调用次数（简称为IP调用次数）是否小于IP维度限制次数，步骤230。在步骤240，根据应用需要调用的用户数据所属的用户的UID、应用的APPKEY以及应用要操作的业务类型，确定在预先设置的第二时间段内该应用对用户的用户数据的已调用次数（简称为用户调用次数）是否小于业务总限制次数，要操作的业务类型调用用户数据的次数（简称为业务类型调用次数）是否小于相应的该业务类型限制次数。在步骤250，如果该应用所在IP地址的IP调用次数小于IP维度限制次数，应用对用户的用户数据的已调用次数小于相应的业务限制次数，并且要操作的业务类型调用用户数据的次数小于该业务类型限制次数，服务器20允许该应用调用开放平台22。进一步，在步骤270，服务器20或者开放平台22将该IP地址的应用调用开放平台22的次数（即IP调用次数）加1，将该应用调用所述用户的用户数据的调用次数（即用户调用次数）加1，并且将该应用的每一种业务类型对所述用户的用户数据的调用次数（即业务类型调用次数）加1，并将IP调用次数、用户调用次数和要执行的业务类型的相应业务类型调用次数存储在缓存中。由于在每一次调用中，应用可能仅执行多种业务类型中的一种或多种，因此仅将要执行的业务类型的业务类型调用次数加1。在步骤230和240中，如果在第一时间段内该应用的IP地址的IP调用次数不小于IP维度限制次数，或者在第二时间段内，应用对用户的用户数据的调用次数不小于相应的业务限制次数，或者要操作的业务类型调用用户数据的次数不小于该业务类型限制次数，则不允许应用调用开放平台22，不允许应用对开放平台的调用，步骤260。

本发明的实施例中，步骤230和240的执行顺序仅是示例性的。实际上，这两个步骤可以同时执行，也可以任意之一先执行，另一步骤后执行。

图3示出了根据本发明的实施例的在IP维度确定是否允许应用调用开放平台的具体过程。如图3所示，对于步骤230，为了在IP维度确定是否允许应用调用开放平台的过程，首先根据应用的APPKEY从数据库30中获取应用的应用等级，并且根据应用所在的客户端的IP地址和应用的应用等级从数据库30中获取该应用的IP维度限制次数，步骤310。在步骤320，从缓存中读取该应用的IP调用次数。如没有读取到IP调用次数，表明该IP地址的应用是第一次调用开放平台，表明允许应用在IP维度调用开放平台，将IP调用次数设为0，并启动第一计时器，步骤330，然后进行步骤250。如果从缓存中读取到IP调用次数，获取第一计时器的计时值并将第一计时器的计时值与第一时间段进行比较，步骤340。如果第一计时器的计时值小于第一时间段，则将IP调用次数与IP维度限制次数进行比较，步骤350。如果在步骤350确定IP调用次数小于IP维度限制次数，则执行步骤250。如果在步骤350确定IP调用次数不小于IP维度限制次数，则表明在IP维度不允许应用调用开放平台。如果在步骤340确定第一计时器的计时值不小于第一时间段值，则使第一计时器复位，重新开始计时，将IP调用次数设为0（步骤360），然后流程进行到步骤250。

图4示出了根据本发明的实施例的在用户维度确定是否允许应用调用开放平台的具体过程。如图4所示，步骤240，为了在用户维度确定是否允许应用调用开放平台的过程，首先根据应用的APPKEY从数据库中获取应用的应用等级，并根据应用需要调用的用户数据所属的用户的UID和应用的应用等级从数据库30中获取该应用对用户的用户数据的业务总限制次数和每一种业务操作类型的业务类型限制次数，该应用步骤412。在步骤414，从缓存中读取该应用的用户调用次数。如没有读取到用户调用次数，表明该应用是第一次调用开放平台以获得该用户的用户数据，将用户调用次数设为0，将每一种业务类型的业务类型调用次数设为0，并启动第二计时器（步骤416），然后进行步骤250。本发明的优选实施例中，在微博开放平台中，将第一至第三业务类型的业务类型调用次数设为0。如果从缓存中读取到用户调用次数，获取第二计时器的计时值并将第二计时器的计时值与第二时间段进行比较，步骤418。如果第二计时器的计时值小于第二时间段，则将用户调用次数与业务总限制次数进行比较，步骤420。同时，本发明的实施例中，还将存储在缓存中的每一种业务类型的业务类型调用次数与相应的业务类型限制次数比较。具体地，在步骤422，从缓存中获取存储的第一业务类型的业务类型调用次数，将其与第一业务类型的业务类型限制次数比较（步骤424）。如果第一业务类型的业务类型调用次数不小于第一业务类型的业务类型限制次数，则表明在用户维度不允许应用调用开放平台。同时，在步骤426，从缓存中获取存储的第二业务类型的业务类型调用次数，并将其与第二业务类型的业务类型限制次数比较（步骤428）。如果第二业务类型的业务类型调用次数不小于第二业务类型的业务类型限制次数，则表明在用户维度不允许应用调用开放平台。在步骤430，从缓存中获取存储的第三业务类型的业务类型调用次数，将其与第三业务类型的业务类型限制次数比较（步骤432）。本发明中，第三业务类型的业务类型调用次数包括在第二时间段内的业务调用次数和在一天时间内的业务调用次数（存储在缓存中），第三业务类型的业务类型限制次数包括在第二时间段内的第三业务限制次数和一天时间内的第三业务限制次数（存储在数据库30中）。如果第三业务类型的业务类型调用次数不小于第三业务类型的业务类型限制次数，或者第三业务类型的在一天时间内的业务调用次数不小于一天时间内的业务类型限制次数，则表明在用户维度不允许应用调用开放平台。只有第一业务类型的业务类型调用次数小于第一业务类型的业务类型限制次数，第二业务类型的业务类型调用次数小于第二业务类型的业务类型限制次数，并且第三业务类型的业务类型调用次数小于第三业务类型的业务类型限制次数，在用户维度允许应用调用开放平台。

如果在步骤418确定第二计时器的计时值不小于第二时间段值，则使第二计时器复位，重新开始计时，将用户调用次数设为0，将每一种业务类型的业务类型调用次数设为0（步骤432），然后流程进行到步骤250。

本发明中，开放平台22预先划分设定应用的应用等级，并且为每一等级的应用预设IP限制次数、业务总限制次数和应用的每一种业务操作类型的业务类型限制次数的具体数值并存储在数据库30中。需要使用开放平台22的第三方开发的应用需要预先向开放平台22进行注册。应用预先向开放平台22发出应用注册请求，当开放平台22接收到应用注册请求时，开放平台22将分配给该应用一个唯一的应用标识APPKEY，并对该应用进行授权。具体地，如果一个应用注册时，该应用没有被审核通过，则仅给该应用授予测试授权；在对应用进行审核时，根据应用的使用人数，应用的质量，授予应用相应的应用等级，并将应用的APPKEY以及应用等级信息存储在数据库中。

同样，需要使用服务系统的用户也需要预先向服务系统进行注册。当用户进行注册时，服务系统为该用户分配一个唯一的用户标识UID。对于注册后的用户，服务系统将该用户的相关信息存储在数据库30中。

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

Claims (11)

1.一种限制开放平台的调用的方法，包括：

接收应用发出的开放平台调用消息；

从接收到的开放平台调用消息中解析出应用所在的客户端的IP地址，应用的应用标识APPKEY，应用需要操作的业务类型和需要调用的用户数据所属的用户的用户标识UID；

根据应用的APPKEY和应用所在的客户端的IP地址，确定该应用在预先设置的第一时间段内对开放平台的IP调用次数是否小于IP维度限制次数；

根据所述用户的UID、应用的APPKEY以及应用要操作的业务类型，确定在预先设置的第二时间段内该应用对所述用户数据的用户调用次数是否小于业务总限制次数，要操作的业务类型的业务类型调用次数是否小于相应的业务类型限制次数；

如果所述IP调用次数小于IP维度限制次数，所述用户调用次数小于相应的业务限制次数，并且要操作的业务类型的业务类型调用次数小于该业务类型限制次数，允许该应用调用开放平台；如果所述IP调用次数不小于IP维度限制次数，或者所述用户调用次数不小于相应的业务限制次数，或者要操作的业务类型的业务类型调用次数不小于该业务类型限制次数，不允许该应用调用开放平台。

2.根据权利要求1所述的方法，进一步包括步骤：

将该IP地址的应用的IP调用次数加1，将该应用的用户调用次数加1，并且将该应用的要操作的每一种业务类型的业务类型调用次数加1，然后将IP调用次数、用户调用次数和要执行的业务类型的业务类型调用次数存储在缓存中。

3.根据权利要求1所述的方法，其中，根据应用的APPKEY和应用所在的客户端的IP地址，确定该应用在第一时间段内对开放平台的IP调用次数是否小于IP维度限制次数包括：

根据应用的APPKEY从数据库中获取应用的应用等级，并且根据应用的IP地址和应用等级从数据库中获取该应用等级的应用的IP维度限制次数；

从缓存中读取该应用的IP调用次数，将所述应用的IP调用次数与IP维度限制次数进行比较以确定在IP维度是否允许应用调用开放平台。

4.根据权利要求3所述的方法，其中，从缓存中读取该应用的IP调用次数，将所述应用的IP调用次数与IP维度限制次数进行比较以确定在IP维度是否允许应用调用开放平台包括：

如没有读取到该应用的IP调用次数，将该应用的IP调用次数设为0，并启动第一计时器，在IP维度允许应用调用开放平台；

如果从缓存中读取到IP调用次数，获取第一计时器的计时值并将第一计时器的计时值与第一时间段进行比较；

如果第一计时器的计时值小于第一时间段，将IP调用次数与IP维度限制次数进行比较，仅当确定IP调用次数小于IP维度限制次数时在IP维度允许应用调用开放平台；

如果第一计时器的计时值不小于第一时间段值，使第一计时器复位并重新开始计时，将IP调用次数设为0，在IP维度允许应用调用开放平台。

5.根据权利要求1所述的方法，其中，根据所述用户的UID、应用的APPKEY以及应用要操作的业务类型，确定在第二时间段内该应用对所述用户数据的用户调用次数是否小于业务总限制次数，要操作的业务类型的业务类型调用次数是否小于相应的业务类型限制次数包括：

根据应用的APPKEY从数据库中获取应用的应用等级，并根据应用需要调用的用户数据所属的用户的UID和应用的应用等级从数据库中获取该应用等级的应用对用户的用户数据的业务总限制次数和每一种业务操作类型的业务类型限制次数；

从缓存中读取该应用的用户调用次数，将所述应用的用户调用次数与业务总限制次数进行比较以确定在用户维度是否允许应用调用开放平台。

6.根据权利要求5所述的方法，其中，从缓存中读取该应用的用户调用次数，将所述应用的用户调用次数与业务总限制次数进行比较以确定在用户维度是否允许应用调用开放平台包括：

如没有从缓存中读取到用户调用次数，将用户调用次数设为0，将每一种业务类型的业务类型调用次数设为0，并启动第二计时器，在用户维度允许应用调用开放平台；

如从缓存中读取到用户调用次数，获取第二计时器的计时值并将第二计时器的计时值与第二时间段进行比较；

如果第二计时器的计时值小于第二时间段，则将用户调用次数与业务总限制次数进行比较，将存储在缓存中的每一种业务类型的业务类型调用次数与相应的业务类型限制次数比较，仅当确定用户调用次数小于业务总限制次数，并且每一种业务类型的业务类型调用次数小于相应的业务类型限制次数时在用户维度允许应用调用开放平台；

如果第二计时器的计时值不小于第二时间段值，使第二计时器复位并重新开始计时，将用户调用次数设为0，并将每一种业务类型的业务类型调用次数设为0，在用户维度允许应用调用开放平台。

7.根据权利要求6所述的方法，其中，将存储在缓存中的每一种业务类型的业务类型调用次数与相应的业务类型限制次数比较包括：

将缓存中存储的第一业务类型的业务类型调用次数与第一业务类型的业务类型限制次数比较；

将缓存中存储的第二业务类型的业务类型调用次数与第二业务类型的业务类型限制次数比较；

将缓存中存储的第三业务类型的业务类型调用次数与第三业务类型的业务类型限制次数比较。

8.根据权利要求7所述的方法，其中，将缓存中存储的第三业务类型的业务类型调用次数与第三业务类型的业务类型限制次数比较包括：

将第三业务类型的在第二时间段内的业务调用次数与第三业务类型在第二时间段内的第三业务限制次数比较；

将第三业务类型的在一天时间内的业务调用次数与第三业务类型在一天时间内的业务限制次数比较。

9.根据权利要求7或8所述的方法，其中，第一至第三业务类型分别为发微博、发评论和加关注。

10.根据权利要求1所述的方法，其中，所述应用标识APPKEY是应用向开放平台注册时由开放平台分配的唯一的应用标识，所述用户标识UID是在用户注册为该用户分配的唯一的用户标识。

11.根据权利要求3或5所述的方法，其中，应用的应用等级、IP限制次数、业务总限制次数和每一种业务操作类型的业务类型限制次数是由开放平台预先设置的。