CN115333876A - 一种应用程序接口api网关计费方法、装置及存储介质 - Google Patents

Abstract

本发明公开了一种应用程序接口API网关计费方法、装置及存储介质，方法包括：获取支付请求，根据支付请求确定支付信息和比率规则；基于比率规则，根据支付信息向目标账户增加目标点数，确定目标账户的点数信息；获取API接口调度请求，根据API接口调度请求确定标识信息；根据标识信息，确定第一计费规则和第二计费规则，并获取点数信息；其中，第一计费规则为目标账户的计费规则，第二计费规则为目标API的计费规则；基于点数信息，根据第一计费规则和第二计费规则，对目标API的调度进行计费。本发明提供了支持全球化、多货币体系的API开放的方案，可以支持多种货币汇率和波动，方便全球开发者使用API，保障开发者的收益，可广泛应用于API网关计费技术领域。

Description

一种应用程序接口API网关计费方法、装置及存储介质

技术领域

本发明涉及API网关计费技术领域，尤其是一种应用程序接口API网关计费方法、装置及存储介质。

背景技术

随着IT技术和企业业务的快速发展，很多情况下企业需要借助外部合作伙伴提供的能力去实现业务，例如在能源互联网领域的设备控制调用接口、设备数据调用接口、设备用户调用接口、光伏发电预测接口等信息的交换。企业将自己的能力、服务、数据以API的形式开放给合作伙伴使用，合作伙伴借助企业提供的API能力进行利用形成自身价值，这样企业与合作伙伴形成深度合作的关系，共同做大做强业务。

API是应用程序编程接口的意思，开放API就是开放应用程序编程接口。可以说程序开放API就是说开放接口，以让别人的程序能够调用你的程序数据。就产生了两个角色，API 的开发者和API的用户。API网关，APIGataway，对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为本发明实施例提供的流程架构示意图；

图3为本发明实施例提供的点数充值流程示意图；

图4为本发明具体实施例1和2(实时计费+按次固定计费)对应的流程示意图；

图5为本发明具体实施例3(实时计费+按次阶梯计费)对应的流程示意图；

图6为本发明具体实施例4(实时计费+按量计费)对应的流程示意图；

图7为本发明具体实施例5(实时计费+按时计费)对应的流程示意图；

图8为本发明具体实施例6和7(后计费+按次固定计费)对应的流程示意图；

图9为本发明具体实施例8(后计费+按次阶梯计费)对应的流程示意图；

图10为本发明具体实施例9(后计费+按量计费)对应的流程示意图；

图11为本发明具体实施例10(后计费+按时计费)对应的流程示意图；

图12为本发明具体实施例11(不计费)对应的流程示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

针对现有技术存在的问题，一方面，本发明实施例提供了一种应用程序接口API网关计费方法，参照图1，包括：

获取支付请求，根据支付请求确定支付信息和比率规则；其中，支付信息包括货币种类和支付金额；

基于比率规则，根据支付信息向目标账户增加目标点数，确定目标账户的点数信息；

获取API接口调度请求，根据API接口调度请求确定标识信息；

根据标识信息，确定第一计费规则和第二计费规则，并获取点数信息；其中，第一计费规则为目标账户的计费规则，第二计费规则为目标API的计费规则；

基于第一计费规则和第二计费规则，对目标API的调度进行计费。

需要说明的是，点数信息为目标账户增加了目标点数后的账户点数余额。

可选地，方法还包括：

当目标账户的账户余额小于目标API的调度的计费数额，或，当目标账户的账户余额为负，将预设提示信息发送至API接口调度请求对应的用户端；其中，账户余额根据点数信息确定。

可选地，接收支付请求，根据支付请求确定支付信息和比率规则，包括：

接收支付请求，根据支付请求确定支付信息和渠道信息；

根据支付信息的货币种类和渠道信息匹配并确定对应的比率规则。

具体地，用户通过支付请求为其点数账户进行充值，根据支付的渠道对应的规则，确认其获得点数。渠道信息即为用户的支付渠道，包括了PayPal支付、银行卡支付等多种支付渠道，各个支付渠道的支付方式有预设的比率点数规则。

可选地，基于比率规则，根据支付信息向目标账户增加目标点数，包括：

基于比率规则，根据支付信息的支付金额计算得到点数结果；

根据点数结果，向目标账户增加目标点数；

确定增加目标点数后的目标账户的点数信息。

可选地，根据标识信息，确定第一计费规则和第二计费规则，并获取点数信息，包括：

根据标识信息，确定目标账户的第一计费方式和计费周期，以及目标API的第二计费方式，并获取目标账户的所述点数信息。

可选地，第一计费方式，包括：

对目标API的调度进行实时计费处理；

或，对目标API的调度进行后计费处理；

或，对目标API的调度进行不计费处理。

具体地，每个账户都具有计费方式的标识，以确认计费方式，实时计费(在调用成功时，即进行扣除点数)、后计费(在调用成功后，根据计费周期进行扣除点数)、不计费(调用成功无需扣除点数)。需要说明的是，后计费方式关联了计费周期，即在调用时间达到预设周期后对周期内的API调用进行统一计费。

可选地，第二计费方式，包括：

对目标API的调度进行按次固定计费处理；

或，对目标API的调度进行按次阶梯计费处理；

或，对目标API的调度进行按量计费处理；

或，对目标API的调度进行按时计费处理费。

具体地，通过预设的计费规则关联需要计费的API，计费规则具有四种方式，分别是：按次固定(每次调用成功扣除点数均为固定值，例如：每次扣除点数均为20点)、按次阶梯(在一定时长内，按照调用成功的总量进行收费，含阶梯计量，例如：在一年度内，第1次至第 100次调用成功时，每次均扣除20点；第101次至200次调用成功时，每次均扣除15点；第201次至2500次调用成功时，每次均扣除10点等，如此类推)、按量(在一定时长内，按照累计调用次数扣除点数，例如：在一年度内，每500次用成功时，扣除1500点)、按时 (在一定时长内，无论调用次数是多少均不扣除点数，例如，在一年度内不论次数均不扣除点数)，计费规则在按量、按时的情况下，可以指定按组或按单个API进行关联，按组关联则该组内API共享规则中的计费规则，还需要说明的是，按时计费方式可以为预支付点数或后支付点数，即仅在预设时长之前或之后进行一次点数扣除，在预设时长期间不再进行点数扣除。API通过以上四种种方式配置点数消耗数量。

另一方面，本发明实施例提供了一种应用程序接口API网关计费装置，包括：

第一模块，用于获取支付请求，根据支付请求确定支付信息和比率规则；其中，支付信息包括货币种类和支付金额；

第二模块，用于基于比率规则，根据支付信息向目标账户增加目标点数；

第三模块，用于获取API接口调度请求，根据API接口调度请求确定标识信息；

第四模块，用于根据标识信息，确定第一计费规则和第二计费规则，并获取点数信息；其中，第一计费规则为目标账户的计费规则，第二计费规则为目标API的计费规则，点数信息包括目标账户的点数余额；

第五模块，用于基于第一计费规则和第二计费规则，对目标API的调度进行计费。

本发明方法实施例的内容均适用于本装置实施例，本装置实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。

本发明实施例的另一方面还提供了一种电子设备，包括处理器以及存储器；

存储器用于存储程序；

处理器执行所述程序实现如前面的方法。

本发明方法实施例的内容均适用于本电子设备实施例，本电子设备实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。

本发明实施例的另一方面还提供了一种计算机可读存储介质，存储介质存储有程序，程序被处理器执行实现如前面的方法。

本发明方法实施例的内容均适用于本计算机可读存储介质实施例，本计算机可读存储介质实施例所具体实现的功能与上述方法实施例相同，并且达到的有益效果与上述方法达到的有益效果也相同。

本发明实施例还公开了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器可以从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行前面的方法。

下面详细描述本发明的应用程序接口API网关计费的实现原理：

为了对本发明的实现原理进行充分说明，首先对相关技术内容进行解释说明：

应用程序接口(英语：Application Programming Interface，简称：API)，又称为应用编程接口，API之主要目的是提供应用程序与开发人员以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。提供API所定义的功能的软件称作此API的实现。API是一种接口，故而是一种抽象。

应用程序接口为：“‘电脑操作系统(Operating system)’或‘程序库’提供给应用程序调用使用的代码”。其主要目的是让应用程序开发人员得以调用一组例程功能，而无须考虑其底层的源代码为何、或理解其内部工作机制的细节。API本身是抽象的，它仅定义了一个接口，而不涉及应用程序在实际实现过程中的具体操作。通过API接口，开放平台的用户可以不需要了解具体的实现过程而直接获得结果，方便用户完成不同的业务功能。

针对现有技术存在的问题，本发明拟解决的问题是，针对目前API单一的收费模式，并且使用场景主要面向单一国内，没有考虑到全球化下不同地区、不同货币的实际情况，特别是在地缘格局和其他因素影响下的经济波动。因此，参照图2，本发明的目的在于提供多样化灵活的计量和适合汇率波动的方法：

首先，每一个API调用的用户都会一个点数账户，并且该账号具有计费方式和计费周期的标识，计费方式分别有：实时计费(在调用成功时，即根据API的计费规则进行扣除点数)、后计费(在调用成功后，根据API的计费规则和账号的计费周期进行扣除点数)、不计费(调用成功无需扣除点数)，计费周期关联后计费方式，分别有：按分钟，按小时、按天，可以累加设置；该点数账户的点数可以增加和减少。

然后，在API网关管理侧，通过比率规则设置点数在不同规则的增加比率，如规则1每一单位增加点数值10点，规则2每1单位增加点数值15点。

接着，设置不同渠道的订单匹配，在订单完成时执行比率规则，用户完成支付订单后自动按照比率规则增加其点数。

然后，通过设置计费规则关联需要计费的API，计费规则具有四种方式，分别是：按次固定(每次调用成功扣除点数均为固定值，例如：每次扣除点数均为20点)、按次阶梯(在一定时长内，按照调用成功的总量进行收费，含阶梯计量，例如：在一年度内，第1次至第100次调用成功时，每次均扣除20点；第101次至200次调用成功时，每次均扣除15点；第201次至2500次调用成功时，每次均扣除10点等，如此类推)、按量(在一定时长内，按照累计调用次数扣除点数，例如：在一年度内，每500次调用成功时，扣除1500点)、按时(在一定时长内，无论调用次数是多少均不扣除点数，例如，在一年度内不论次数均不扣除点数)，计费规则在按量、按时的情况下，可以指定按组或按单个API进行关联，按组关联则该组内API共享规则中的计费规则。API通过以上四种方式配置点数消耗数量。

然后，具体的调用过程中，用户在用户侧需要具备一组应用信息(包含APP_KEY和APP_SECRET)，网关凭借APP_KEY和APP_SECRET获取调用户账号的计费方式(若计费方式为后计费，还需要获得用户的计费周期)和用户请求调用的的API的计费规则，通过用户账号的计费方式和调用请求API的计费规则，进行计费计量判定，若计费计量不通过，则将预设提示信息发送到调用申请的用户端；若通过，则进入下一步。

最后，通过判定的调用即可与服务进行交互，由具体服务返回最终调用的结果，并且该结果在临时数据库中通过键值Key-Value储存。

下面结合附图和实施例对本方案进一步说明，所述说明用于解释本发明的实现原理，不能看作对本发明的限制。

参照图3，一方面是用户点数账户充值：

管理员首先设置增加比率的规则数值，然后设置具体支付渠道执行的方法，用户通过支付为其点数账户进行充值，根据支付的渠道对应的规则，确认其获得点数。示例：管理员首先设置规则1的增加比率为1：650，规则2的增加比率为1：700，接着设置美国区用户使用 PayPal支付美元金额执行规则1，美国区用户使用银行卡支付执行规则2，美国区用户A通过PayPal在线支付，支付金额为1美元，匹配的点数规则是1：650，支付成功后，用户点数账户增加650点，用户B通过银行卡支付，支付金额为1美元，匹配的点数规则是1：700，支付成功后，用户点数账户增加700点。

另一方面是用户进行接口调度请求：

用户进行接口调度时，触发请求，开始通过请求中的APP_KEY和APP_SECRET，匹配用户信息和用户的计费方式(若计费方式为后计费，还需要获得用户的计费周期)，根据接口调用请求的API，获得该API的计费规则，通过用户账号的计费方式和调用请求API的计费规则，进行计费计量判定，若计费计量不通过，则将预设提示信息发送到调用申请的用户端；

最后，通过判定的调用即可与服务进行交互，由具体服务返回最终调用的结果，并且该结果在临时数据库中通过键值Key-Value储存。

实施例1：参照图4，用户A在通过一组APP_KEY和APP_SECRET对API接口z进行调用请求，网关匹配到请求方是用户A，账户点数500点，计费方式为实时计费，API接口z计费方式为按次固定，每次20点。此时，本次调用请求可通过判定，进入与服务进行交互，服务最终返回成功调用的结果后，账户点数扣减20点剩余480点。

实施例2：参照图4，用户B在通过一组APP_KEY和APP_SECRET对API接口y进行调用请求，网关匹配到请求方是用户A，账户点数100点，计费方式为实时计费，API接口y计费方式为按次固定，每次200点。此时，本次调用请求不通过判定，不进入与服务进行交互，将预设提示信息发送到调用申请的用户端。

实施例3：参照图5，用户C在通过一组APP_KEY和APP_SECRET对API接口x进行调用请求，网关匹配到请求方是用户C，账户点数2020点，计费方式为实时计费，API接口x计费方式为按次阶梯，一年度第1至100次每次20点，第101次至不限次每次15点。在以Redis 为代表的临时数据库以键值Key-Value储存用户C调用成功的次数，用户C在一年度内成功调用时1-100次时每次扣除20点，此时剩余点数20点，在成功调用第101次时扣除15点，剩余点数5点，调用102次时点数不足，则将预设提示信息发送到调用申请的用户端。

实施例4：参照图6，用户D在通过一组APP_KEY和APP_SECRET对API接口w进行调用请求，网关匹配到请求方是用户D，账户点数2020点，计费方式为实时计费，API接口w计费方式为按量且按组关联了API接口w1，扣除2000点包含一年度500次成功调用次数。在以Redis为代表的临时库以键值Key-Value储存用户D调用成功的次数，用户D在一年度内第1次成功调用时开始扣除2000点，用户D在一年度内调用w和w1，合计在500次成功调用次数内，均不再扣除点数，第501次扣除2000点，此时用户D账号点数不足，则将预设提示信息发送到调用申请的用户端。

实施例5：参照图7，用户E在通过一组APP_KEY和APP_SECRET对API接口v进行调用请求，网关匹配到请求方是用户E，账户点数2020点，计费方式为实时计费，API接口v计费方式为按时且按组关联了API接口v1，扣除2000点包含一年度不限的调用次数。在以Redis 为代表的临时库以键值Key-Value储存用户E调用成功的次数，用户E在一年度内第1次成功调用时开始扣除2000点，用户E在一年度内调用v和v1，均不再扣除点数，至下一年用户E再次调用API接口v和v1，此时应该扣除点数2000点，用户E账号点数不足，则将预设提示信息发送到调用申请的用户端。

实施例6：参照图8，用户F在通过一组APP_KEY和APP_SECRET对API接口u进行调用请求，网关匹配到请求方是用户F，账户点数2500点，计费方式为后计费，计费周期为1天，API接口u计费方式为按次固定，每次20点。在以Redis为代表的临时库以键值Key-Value 储存用户F调用成功的次数，在到达1天时统计该周期内调用成功的总次数为50次，则总计应扣除1000点，用户F账户点数足够扣除，扣除后剩余1500点。

实施例7：参照图8，用户G在通过一组APP_KEY和APP_SECRET对API接口t进行调用请求，网关匹配到请求方是用户G，账户点数500点，计费方式为后计费，计费周期为1天，API接口u计费方式为按次固定，每次20点。在以Redis为代表的临时库以键值Key-Value 储存用户F调用成功的次数，在到达1天时统计该周期内调用成功的总次数为50次，则总计应扣除1000点，用户F账户点数不足够扣除，扣除后剩余-500点，此时将预设提示信息发送到调用申请的用户端。第2天用户G在开始调用时，因账户点数为负数，将不能通过判定，并且将预设提示信息发送到调用申请的用户端。

实施例8：参照图9，用户H在通过一组APP_KEY和APP_SECRET对API接口s进行调用请求，网关匹配到请求方是用户H，账户点数2020点，计费方式为后计费，计费周期为1天，API接口s计费方式为按次阶梯，一年度第1至100次每次20点，第101次至不限次每次15 点。在以Redis为代表的临时库以键值Key-Value储存用户H调用成功的次数，用户H在一年度内第一天成功调用了50次，第一天结束时扣除点数为1000点(第1至100次时的总量 50*20)剩余1020点；第二天成功调用了51次，第二天结束时扣除点数为1015点(第1至 100次时的总量50*20+第101次至不限次的总量1*15)剩余5点；第三天成功调用了50次，第三天结束时扣除点数为750点(第101次至不限次的总量50*15)剩余-745点，此时将预设提示信息发送到调用申请的用户端；第四天用户H的调用请求因为账户为负数，将不能通过判定，将预设提示信息发送到调用申请的用户端。

实施例9：参照图10，用户I在通过一组APP_KEY和APP_SECRET对API接口r进行调用请求，网关匹配到请求方是用户I，账户点数2020点，计费方式为后计费，计费周期为1天，API接口r计费方式为按量且按组关联了API接口r1，扣除2000点包含一年度500次成功调用次数。在以Redis为代表的临时库以键值Key-Value储存用户I调用成功的次数，用户I 在一年度内第一天成功调用r和r1合计200次(累计200次)，第一天结束时，无需扣除点数；第二天成功调用r和r1合计200次(累计400次)，第二天结束时，无需扣除点数；第三天成功调用r和r1合计200次(累计600次)，第三天结束时，扣除点数2000点，剩余 20点；第四天成功调r和r1合计300次(累计900次)，第四天结束时，无需扣除点数；第五天成功调用r和r1合计200次(累计1100次)，第五天结束时，扣除点数2000点，剩余-1980点，将预设提示信息发送到调用申请的用户端；第六天用户I的调用请求因为账户为负数，将不能通过判定，将预设提示信息发送到调用申请的用户端。

实施例10：参照图11，用户J在通过一组APP_KEY和APP_SECRET对API接口q进行调用请求，网关匹配到请求方是用户J，账户点数2020点，计费方式为后计费，计费周期为1天，API接口q计费方式为按时且按组关联了API接口q1，扣除2000点包含30天不限的调用次数。在以Redis为代表的临时库以键值Key-Value储存用户J调用成功的次数，用户J 在第一天成功调用q和q1，第一天计费周期结束时，扣除2000点；第二天成功调用q和q1，第二天结束时，不扣除点数，如此类推，在第三十天结束时，均不扣除点数；第三十一天，用户J不成功调用q和q1，第三十一天结束时，不扣除点数；第三十二天，用户J成功调用 q和q1，在第三十二天结束时，扣除2000点剩余-1980点，则将预设提示信息发送到调用申请的用户端。第三十三天开始，用户的调用请求因为账户为负数，将不能通过判定，将预设提示信息发送到调用申请的用户端。

实施例11：参照图12，用户K在通过一组APP_KEY和APP_SECRET对API接口q进行调用请求，网关匹配到请求方是用户K，账户点数-20点，计费方式为不计费，那么用户K无论调用的API接口计费方式是任意一种，均通过判定，进入与服务交互，只记录调用成功次数，而不会扣除点数。

综上所述，本发明是一种可以支持全球化、多货币体系的API开放的方案，可以较为灵活地支持多种货币汇率和波动，让全球开发者都可以使用API，并且保障开发者的收益；同时计费计量的方法也灵活多样，可以支持按次固定、按次阶梯、按量、按时，充分覆盖主流的使用场景；技术方案实现简单高效，安全性高。本发明的有益效果包括：

A.支持多种货币和汇率波动，保障开发者利益

B.计费计量方法可支持实时计费、后计费、不计费三种模式，结合按次固定计费、按次阶梯计费、按量计费、按时计费，组合出来的计费计量方法灵活多样而且实用，覆盖绝大部分的使用场景

C.本发明的点数充值架构中通过点数比率和渠道分离，实现了解耦；计费计量架构中通过用户计费模式和计费周期、被调用的API计费规则分离，实现了解耦。

在一些可选择的实施例中，在方框图中提到的功能/操作可以不按照操作示图提到的顺序发生。例如，取决于所涉及的功能/操作，连续示出的两个方框实际上可以被大体上同时地执行或所述方框有时能以相反顺序被执行。此外，在本发明的流程图中所呈现和描述的实施例以示例的方式被提供，目的在于提供对技术更全面的理解。所公开的方法不限于本文所呈现的操作和逻辑流程。可选择的实施例是可预期的，其中各种操作的顺序被改变以及其中被描述为较大操作的一部分的子操作被独立地执行。

此外，虽然在功能性模块的背景下描述了本发明，但应当理解的是，除非另有相反说明，所述的功能和/或特征中的一个或多个可以被集成在单个物理装置和/或软件模块中，或者一个或多个功能和/或特征可以在单独的物理装置或软件模块中被实现。还可以理解的是，有关每个模块的实际实现的详细讨论对于理解本发明是不必要的。更确切地说，考虑到在本文中公开的装置中各种功能模块的属性、功能和内部关系的情况下，在工程师的常规技术内将会了解该模块的实际实现。因此，本领域技术人员运用普通技术就能够在无需过度试验的情况下实现在权利要求书中所阐明的本发明。还可以理解的是，所公开的特定概念仅仅是说明性的，并不意在限制本发明的范围，本发明的范围由所附权利要求书及其等同方案的全部范围来决定。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM， Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，“计算机可读介质”可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。

计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管已经示出和描述了本发明的实施例，本领域的普通技术人员可以理解：在不脱离本发明的原理和宗旨的情况下可以对这些实施例进行多种变化、修改、替换和变型，本发明的范围由权利要求及其等同物限定。

以上是对本发明的较佳实施进行了具体说明，但本发明并不限于所述实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做出种种的等同变形或替换，这些等同的变形或替换均包含在本申请权利要求所限定的范围内。

Claims (10)

1.一种应用程序接口API网关计费方法，其特征在于，包括：

获取支付请求，根据所述支付请求确定支付信息和比率规则；其中，所述支付信息包括货币种类和支付金额；

基于所述比率规则，根据所述支付信息向目标账户增加目标点数，确定所述目标账户的点数信息；

获取API接口调度请求，根据所述API接口调度请求确定标识信息；

根据所述标识信息，确定第一计费规则和第二计费规则，并获取所述点数信息；其中，所述第一计费规则为所述目标账户的计费规则，所述第二计费规则为目标API的计费规则；

基于所述点数信息，根据所述第一计费规则和所述第二计费规则，对所述目标API的调度进行计费。

2.根据权利要求1所述的一种应用程序接口API网关计费方法，其特征在于，还包括：

当所述目标账户的账户余额小于所述目标API的调度的计费数额，或，当所述目标账户的账户余额为负，将预设提示信息发送至所述API接口调度请求对应的用户端；其中，所述账户余额根据所述点数信息确定。

3.根据权利要求1所述的一种应用程序接口API网关计费方法，其特征在于，所述接收支付请求，根据所述支付请求确定支付信息和比率规则，包括：

接收支付请求，根据所述支付请求确定支付信息和渠道信息；

根据所述支付信息的所述货币种类和所述渠道信息匹配并确定对应的比率规则。

4.根据权利要求1所述的一种应用程序接口API网关计费方法，其特征在于，所述基于所述比率规则，根据所述支付信息向目标账户增加目标点数，确定所述目标账户的点数信息，包括：

基于所述比率规则，根据所述支付信息的所述支付金额计算得到点数结果；

根据所述点数结果，向目标账户增加目标点数；

确定增加所述目标点数后的所述目标账户的点数信息。

5.根据权利要求1所述的一种应用程序接口API网关计费方法，其特征在于，所述根据所述标识信息，确定第一计费规则和第二计费规则，并获取所述点数信息，包括：

根据所述标识信息，确定所述目标账户的第一计费方式和计费周期，以及所述目标API的第二计费方式，并获取所述目标账户的所述点数信息。

6.根据权利要求5所述的一种应用程序接口API网关计费方法，其特征在于，所述第一计费方式，包括：

对所述目标API的调度进行实时计费处理；

或，对所述目标API的调度进行后计费处理；

或，对所述目标API的调度进行不计费处理。

7.根据权利要求5所述的一种应用程序接口API网关计费方法，其特征在于，所述第二计费方式，包括：

对所述目标API的调度进行按次固定计费处理；

或，对所述目标API的调度进行按次阶梯计费处理；

或，对所述目标API的调度进行按量计费处理；

或，对所述目标API的调度进行按时计费处理。

8.一种应用程序接口API网关计费装置，其特征在于，包括：

第一模块，用于获取支付请求，根据所述支付请求确定支付信息和比率规则；其中，所述支付信息包括货币种类和支付金额；

第二模块，用于基于所述比率规则，根据所述支付信息向目标账户增加目标点数，确定所述目标账户的点数信息；

第三模块，用于获取API接口调度请求，根据所述API接口调度请求确定标识信息；

第四模块，用于根据所述标识信息，确定第一计费规则和第二计费规则，并获取所述点数信息；其中，所述第一计费规则为所述目标账户的计费规则，所述第二计费规则为目标API的计费规则；

第五模块，用于基于所述点数信息，根据所述第一计费规则和所述第二计费规则，对所述目标API的调度进行计费。

9.一种电子设备，其特征在于，包括处理器以及存储器；

所述存储器用于存储程序；

所述处理器执行所述程序实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，所述程序被处理器执行实现如权利要求1至7中任一项所述的方法。

Images