CN110213290B - 数据获取方法、api网关以及存储介质 - Google Patents

Abstract

本申请公开了数据获取方法、API网关以及存储介质，获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；将所述第三参数转换为具有预设格式的目标参数；至少将所述目标参数发送至鉴权服务器。本申请API网关在获取API请求后，会将API请求携带的非预设格式的第三参数转换为具有预设格式的目标参数，至少将所述目标参数发送至鉴权服务器，所以API请求中携带的第三参数的格式不必须与鉴权服务器中规定的预设格式一致。

Description

数据获取方法、API网关以及存储介质

技术领域

本申请涉及计算机技术领域，更具体的说，是涉及一种数据获取方法、API网关以及存储介质。

背景技术

API(Application Programming Interface，应用程序编程接口)网关是客户端利用API请求访问一个或多个服务器中存储的各服务方提供的服务对象的统一入口。API网关是将各服务方提供的服务对象聚合起来，所有要调用这些服务对象的客户端都需要通过API网关进行访问。基于这种方式API网关可以对API请求进行统一管控，例如，对API请求进行鉴权。

目前，API网关对API请求进行鉴权的过程如图1所示。API网关12接收到终端11发送的待鉴权的API请求后，从API请求中获取待访问服务对象对应的URL(Uniform ResourceLocator，统一资源定位符)以及用户标识，并将URL以及用户标识发送至鉴权服务器13；参见图1，鉴权服务器13中包括多个权限模型，每一权限模型包括：URL以及权限信息；鉴权服务器13基于接收到URL确定与待鉴权的API请求对应的目标权限模型，并基于接收到的用户标识，以及确定的目标权限模型进行鉴权。若鉴权通过后，API网关12可将API请求发送至存储有相应服务对象的后端服务器14中，后端服务器14基于API请求执行相应的响应操作。

目前，API请求中用户标识和上下文信息的格式必须与鉴权服务器包含的上下文信息和用户标识的格式一致，例如名称，否则无法进行鉴权。

发明内容

有鉴于此，本申请提供了一种数据获取方法、API网关以及存储介质，用于解决现有技术API请求中用户标识和上下文信息的格式与鉴权服务器包含的上下文信息和用户标识的格式不一致，导致的无法进行鉴权的问题。

为实现上述目的，本申请提供如下技术方案：

第一方面，一种数据获取方法，应用于应用程序编程接口API网关，包括：

获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

将所述第三参数转换为具有预设格式的目标参数；

至少将所述目标参数发送至鉴权服务器。

第二方面，一种应用程序编程接口API网关，包括：

获取模块，用于获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

转换模块，用于将所述第三参数转换为具有预设格式的目标参数；

发送模块，用于至少将所述目标参数发送至鉴权服务器。

第三方面，一种应用程序编程接口API网关，包括：

存储器，用于存储程序；

处理器，用于执行所述程序，所述程序具体用于：

获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

将所述第三参数转换为具有预设格式的目标参数；

至少将所述目标参数发送至鉴权服务器。

第四方面，一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上述任一项所述的数据获取方法包含的各个步骤。

经由上述的技术方案可知，本申请提供了一种应用于API网关的数据获取方法，API网关在获取API请求后，会将API请求携带的非预设格式的第三参数转换为具有预设格式的目标参数，至少将所述目标参数发送至鉴权服务器，所以API请求中携带的第三参数的格式不必须与鉴权服务器中规定的预设格式一致。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为现有技术API网关对API请求进行鉴权的过程示意图；

图2为由终端、API网关、鉴权服务器以及后端服务器所构成的硬件环境示意图；

图3为本申请实施例公开的一种应用于应用程序编程接口API网关的数据获取方法流程图；

图4为本申请实施例公开的API网关的一种实现方式的结构示意图；

图5为本申请实施例公开的API网关的设备硬件结构框图。

具体实施方式

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

本申请公开了一种应用于应用程序编程接口API网关的数据获取方法、API网关以及可读存储介质。

在一可选实施例中，API网关可为服务器/平台的一个硬件组成部分，也可为功能模块或组件。上述服务器或平台可以是一台服务器，也可以是由若干台服务器组成的服务器集群，或者是一个云计算服务中心。

在一可选实施例中，上述数据获取方法可以应用于图2所示的由终端11、API网关12、鉴权服务器13以及后端服务器14所构成的硬件环境中。

终端11可以是诸如台式机、移动终端(例如智能手机)、ipad等电子设备。

用户可以在终端11进行操作；终端11可以基于用户的操作行为生成待鉴权的API请求，并将其发送至API网关12。

上述API请求可以携带有参数，例如用户标识、上下文信息、URL等。本申请实施例中，不同API请求携带的参数可能不同，例如，用于更新主机信息的API请求携带的参数可以包括主机标识以及要更改的信息；用于审批程序的API请求携带的参数可以包括申请人信息以及申请的内容等。

API网关12可以从终端11发送的待鉴权的API请求中，获取用于进行鉴权的第三参数，并将该第三参数转换为目标参数，并将目标参数发送至鉴权服务器13。这里，目标参数为具有预设格式的参数，鉴权服务器13可以基于该具有预设格式的目标参数来验证API请求的权限模型。

在一可选实施例中，预设格式可以包括符合API规范设定的参数名称。目前API请求携带的参数的名称必须符合API规范设定的参数名称规范，否则API网关12与鉴权服务器13无法识别API请求中携带的参数，从而使得无法进行鉴权。例如，若API规范设定的参数名称中用户标识的名称为user_id，若API请求中携带的用户标识的名称为idtifiy，则API网关12无法从API请求中获得用户标识这一参数。

可以理解的是，API请求携带的第三参数的参数名称可能不符合API规范，例如用户自定义的名称，为了能够使得本申请中的API网关12能够从API请求中获取不符合API规范设定的第三参数，可选的，API网关包括各种不符合API规范的参数名称与符合规范的参数名称的对应关系，例如，API网关包括idtifiy、ID分别与user_id对应。API网关通过不符合API规范设定的参数名称与符合规范的参数名称的对应关系，可以从API请求中获得用于进行鉴权的第三参数。

为使得鉴权服务器13能够识别第三参数，可以将不符合预设格式的第三参数转换为目标参数，例如，将API请求中携带的不符合API规范设定的参数名称的第三参数转换成符合API规范设定的参数名称的目标参数。从而使得鉴权服务器13可以识别该目标参数，从而可以进行鉴权。

需要说明的是，针对同一类型的API请求，其中携带的参数(例如用户标识、上下文信息等)不同，得到的对应的目标参数也不同。这里，同一类型的API请求是指至少具有相同URL的请求，其中同一类型的不同API请求携带的参数(例如用户标识、上下文信息等)可以不同。

本申请可以在鉴权服务器13上或独立于鉴权服务器13设置数据库15。数据库15用于存储权限模型。鉴权服务器13可以从数据库15中获取权限模型。则鉴权服务器13接收到API网关12发送的目标参数后，可以基于该目标参数以及与该API请求对应的权限模型，对上述待鉴权的API请求进行鉴权。

在一可选实施例中，数据库15存储的权限模型至少可以包括URL以及权限信息。当然，权限模型除包括URL以及权限信息外，还可以包括上下文信息，该上下文信息是指针对待操作对象的待操作内容，例如要对主机进行开机操作，则主机即为待操作对象，开机为待操作内容。

可选的，权限模型的实现形式可以包括以下至少一种：表格、函数、结构体以及数据结构。本申请实施例不对权限信息的具体内容进行限定，例如权限信息可以是访问权限、控制权限、操作权限、增加权限、删除权限等。

下面对鉴权服务器13对待鉴权的API请求进行鉴权的过程进行说明。

鉴权服务器13可以包括用户标识绑定的用户角色以及用户角色对应的一个或多个权限信息。鉴权服务器13接收到URL、上下文信息以及用户标识后，基于URL从多个权限模型中获取目标权限模型，确定目标权限模型包含的上下文信息是否与接收到的上下文信息(这里的上下文信息为具有规定的预设格式的信息)相同，若相同，从目标权限模型中获得URL对应的权限信息，鉴权服务器13基于接收到的用户标识确定该用户标识对应的用户角色，并确定该用户角色对应的权限信息，若接收到的用户标识对应用户角色具有的权限信息与接收到的URL对应的权限信息相同，则确定鉴权成功，否则鉴权失败，鉴权服务器13将鉴权成功的信息发送至API网关，由API网关将API请求发送至存储有相应服务对象的后端服务器14中。

本申请API网关12具有将API请求中携带的参数(例如用户标识和上下文信息)转换为具有预设格式的目标参数的能力，因此API请求中携带的参数的格式不必须与鉴权服务器中规定的预设格式一致。

下面结合图3，对上述本申请提及的数据获取方法进行说明。参见图3，为本申请公开的一种应用于API网关的数据获取方法流程图，该方法可以包括：

步骤S300、获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种。

在一可选实施例中，本申请中的上下文信息是指针对待操作对象的待操作内容，例如要对主机进行开机操作，则主机即为待操作对象，开机为待操作内容。

上述用户标识为用于操作待操作对象的用户的标识，例如，待操作对象为主机，操作主机的用户可以为用户A、用户B、用户C等等。可以理解的是，不同用户对应的用户标识不同。

需要说明的是，上述第三参数中的“第三”仅用于区分不同的参数，并非限定参数的先后顺序；上述第二上下文信息中的“第二”仅用于区分不同的上下文信息，并非限定上下文信息的先后顺序。同理，下述本申请实施例即将提及的第一参数以及第一上下文信息中的“第二”，以及第二参数中的“第二”也仅用于区分，而非限定参数以及上下文信息的先后顺序。

步骤S310、将所述第三参数转换为具有预设格式的目标参数。

API网关12接收到终端11发送的待鉴权的API请求后，至少可以从API请求中获取用于进行鉴权的第三参数。可以理解的是，不同用户针对第三参数的格式的定义不同，若API请求中携带的第三参数的格式与API规范规定的预设格式不同，那么可能出现鉴权服务器13无法识别第三参数的情况，从而无法鉴权。基于此，本申请API网关可以将API请求中携带的第三参数转换为具有预设格式的目标参数，以使得鉴权服务器13可以识别第三参数对应的目标参数，实现鉴权。

步骤S320、至少将所述目标参数发送至鉴权服务器。

可选的，API网关12还可以将URL发送至鉴权服务器13，从而鉴权服务器13可以基于接收到URL确定与待鉴权的API请求对应的目标权限模型，并基于接收到的目标参数，以及确定的目标权限模型进行鉴权。具体鉴权方法详细可参照前述实施例介绍，在此不再详细赘述。

本申请提供了一种应用于API网关的数据获取方法，API网关在获取API请求后，会将API请求携带的非预设格式的第三参数转换为具有预设格式的目标参数，至少将所述目标参数发送至鉴权服务器，所以API请求中携带的第三参数的格式不必须与鉴权服务器中规定的预设格式一致。

本申请实施例提供的将第三参数转换为具有预设格式的目标参数的方式有多种，本申请实施例提供但不限于以下方式。

A1、根据预先构建的多个API模型，获取第二参数对应的目标API模型。

其中，API请求还可以携带有表征API模型的属性标识的第二参数。

在一可选实施例中，第二参数至少可以包括待访问服务对象的URL。在另一可选实施例中，第二参数可以包括待访问服务对象的URL以及提交方式信息。

这里，提交方式信息用于表征发送API请求的客户端与存储待访问服务对象的服务器的交互方式。

可选的，提交方式信息至少可以包括下述任一种：

第一种，GET请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器请求一个文件，这里HTTP表征从发送API请求的客户端到存储待访问服务对象的服务器端的请求消息。

第二种，POST请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器发送数据让存储待访问服务对象的服务器进行处理。

第三种，PUT请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器请求新增文件，或使用请求中的有效负载替换目标文件。

第四种，DELETE请求：HTTP客户端发送请求的类型，表示向存储待访问服务对象的服务器请求删除文件。

可选的，一个或多个API模型可以存储在API网关12中，具体可以参见图2。可选的，可以预先构建多个API模型，例如图2所示“API模型1”至“API模型n”，其中n≥2。

A2、从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系。

在一可选实施例中，可以将第三参数与目标参数的对应关系进行整理，例如，按照API请求的类型进行整理，以得到不同API请求类型分别对应的“第三参数与目标参数的对应关系”(本申请实施例称“第三参数与目标参数的对应关系”为绑定规则)，可选的，每一API请求类型对应的“第三参数与目标参数的对应关系”可以对应一API模型。

在一可选实施例中，可以基于API请求携带的URL划分API请求的类型，例如，将携带相同URL的API请求划分为一类。相应的，第二参数包括URL。

在一可选实施例中，可以基于API请求携带的URL以及提交方式信息划分API请求的类型，例如，携带有相同URL且携带有相同提交方式信息的API请求属于同一类API请求。相应的第二参数包括URL以及提交方式信息。

本申请实施例中，将能够区分API请求类型的信息称为API模型的属性标识。

下面以URL以及提交方式信息为API模型的属性标识为例，对API模型进行说明。下面API模型的表现形式仅为一种示例，除此之外还可以有其它表现形式，例如结构体、数据结构、表格等。

本申请示例的API模型1如下：

假设待鉴权的API请求如下：

POST/executeVmAction

{"action":"start",

"instance_id":"123",}

其中，待鉴权的API请求携带的第二参数包括：executeVmAction以及POST，从而可以确定上述示例的API模型1为目标API模型。

若API请求携带的第三参数为instance_id，那么，从目标API模型中确定的目标绑定规则为"source":{"context":{"name":"instance_id","source":"body"}},"target":"resourceId"，即第三参数instance_id与目标参数resourceId对应，可选的，可以将第三参数instance_id的值赋值给目标参数resourceId。

A3、基于所述目标绑定规则，将所述第三参数的值赋值给具有所述预设格式的所述目标参数。

若第三参数为非规定的预设格式，则鉴权服务器13可能无法识别该第三参数，因此本步骤可以基于目标API模型中确定的目标绑定规则，将第三参数的值赋值给具有预设格式的目标参数，从而使得鉴权服务器13可以识别第三参数对应的目标参数，从而可以对待鉴权的API请求进行鉴权。

本申请实施例中除了采用API模型表示第三参数与目标参数的对应关系外，还可以用表格的形式表征第三参数与目标参数的对应关系。如表1所示。

表1第三参数与目标参数的对应关系

上述表1中目标参数user_id、resourceid以及nameid均为具有预设格式的参数。

当然，上述表1所示的第三参数与目标参数的对应关系仅为一种可选的示例，除此之外还可以有其他展现形式，例如函数、结构体、数据结构等。

例如，若API请求携带的第三参数的名称为instance_id，则可以在上述表1所示的第三参数与绑定规则的对应关系中查找instance_id对应的目标参数，进而可以将第三参数instance_id的值赋值给目标参数resourceId。

在一可选实施例中，上述A2，从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则的过程包括但不限于以下两种实现形式。

第一种，可以基于API模型中的至少一个绑定规则，以及待鉴权的API请求携带的第三参数，确定目标绑定规则，该过程具体可以包括：

B1、遍历所述目标API模型包含的至少一个绑定规则。

每一API模型可以包括至少一个绑定规则，则本步骤可以通过遍历的方式从目标API模型包括的至少一个绑定规则中查找目标绑定规则。

可选的，本申请实施例中的遍历方式可以为：从前至后遍历，或，从后至前遍历。

例如，若待鉴权的API请求携带的第三参数为instance_id，则可以从前往后遍历目标API模型(以示例的API模型1为例)，即首先查看目标API模型包含的第一个绑定规则，由于该绑定规则包括的参数为user，与待鉴权的API请求携带的第三参数不同；则可以继续遍历第二个绑定规则，由于该绑定规则包括的参数为instance_id，与待鉴权的API请求携带的第三参数相同，因此可以将该第二个绑定规则确定为目标绑定规则。

B2、将包含所述第三参数的绑定规则，确定为所述目标绑定规则。

可以理解的是，目标API模型包含的绑定规则中，至少一个绑定规则包含第三参数，则本步骤可以将该包含第三参数的绑定规则，确定为目标绑定规则。

第二种，每一API模型包括一个或多个权限名称，一个权限名称对应一个或多个绑定规则，可以首先确定目标绑定规则对应的目标权限名称，再从目标权限名称对应的一个或多个绑定规则中，确定目标绑定规则，该过程具体可以包括：

C1、从所述目标API模型包含的至少一个权限名称中，获取与第一参数对应的目标权限名称。

API请求携带有第一参数，第一参数包括用户标识和第一上下文信息中的至少一种。

需要说明的是，本申请实施例中第一参数与第三参数可以相同，可以不同，即第一上下文信息与第二上下文信息可以相同可以不同。第一参数和第三参数两者的用途分别为：第一参数用于获取权限名称；第三参数用于获取具有预设格式的目标参数，以便后续进行鉴权。

可选的，上述预先构建的API模型除可以包括绑定规则外，还可以包括API请求携带的至少一个参数与权限名称的对应关系。

例如，本申请示例的另一API模型2可以如下：

本申请实施例中每一API模型可以包括至少一个权限名称，例如示例的API模型2中包括两个权限名称，即startVM以及stopVM，则本步骤可以从目标API模型包含的至少一个权限名称中，获取第一参数对应的目标权限名称。假设第一参数为restart，那么其对应的目标权限名称为startVM。

C2、获取所述目标权限名称对应的目标绑定规则。

可选的，本申请实施例可以基于目标API模型包括的至少一个参数分别与权限名称的对应关系，得到待鉴权的API请求携带的第一参数对应的目标权限名称，进而可以基于该目标权限名称，得到目标API模型中的目标绑定规则(上述API模型2中，目标绑定规则以函数形式展现)。

例如，若待鉴权的API请求携带的第一参数为start，第二参数为executeVmAction以及POST，第三参数为instance_id，则基于第一参数start，得到的第一参数对应的目标权限名称为startVM。进而基于该目标权限名称，从目标API模型得到的该目标权限名称对应的目标绑定规则为：instance_id与resourceId对应，即可以将instance_id与resourceId进行绑定。

目前的鉴权服务器13中的权限模型可以包括URL、上下文信息(可选)以及权限信息。其中，上下文信息(可选)是指，权限模型可以包括上下信息，也可以不包括上下文信息。鉴权服务器13可以基于API请求携带的URL查找对应的权限模型，因此权限模型与API请求一一对应，即必须有相同的URL，使得API请求与权限模型强耦合。

为了使得API请求与权限模型解耦合，本申请可以在增加权限名称的基础上，对上述API模型做进一步改进，使得API模型包含至少一个参数分别对应的权限名称。使得API网关12可以基于API请求携带的参数确定相应的目标权限名称，并将目标权限名称发送至鉴权服务器13，使得鉴权服务器13基于目标权限名称得到目标权限模型。可选的，本申请鉴权服务器13中的权限模型至少包括权限名称以及与权限名称对应的权限信息，不包括URL。即在鉴权服务器中构建权限模型时，无需考虑URL，即无需考虑其针对的API请求。

由于API请求可以携带参数，不同的参数对应的权限名称可能相同，可能不同，具体根据实际情况而定，即不同类型或同一类型的API请求携带的不同参数对应的权限名称可能相同，可能不同，也就是一个API请求可能与其他API请求共用一个权限模型，即API请求与权限模型并不是一一对应的，即构建一个API请求后，并不一定必须构建相应的权限模型。若同一类型的多个API请求携带的参数不同，那么对应的权限名称可能不同，也就是一个类型的API请求可能对应多个权限模型，即构建一个权限模型后，并不一定必须构建相应类型的API请求，即API请求与权限模型不再必须是一一对应的关系，API请求与权限模型完全解耦合。

可选的，上述基于改进后的API模型，对待鉴权的API请求进行鉴权的过程具体可以包括：

D1、从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称。

本步骤与上述C1对应，详细可参照前述介绍，在此不再详细赘述。

D2、至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据。

其中，一个API模型包含的不同权限名称对应不同的权限模型。

在一可选实施例中，本申请的鉴权服务器13中的权限模型可以包括：权限名称、上下文信息以及权限信息。鉴权服务器13基于接收到的目标权限名称，确定目标权限模型，若目标权限模型包含的上下文信息与API请求携带的上下文信息相同，则从目标权限模型中获得目标权限名称对应的权限信息，鉴权服务器13基于API请求携带的用户标识确定该用户标识对应的用户角色，并确定该用户角色对应的权限信息，若用户标识对应用户角色具有的权限信息与目标权限模型中目标权限名称对应的权限信息相同，则确定鉴权成功，否则鉴权失败。鉴权服务器13还可以将鉴权成功的信息发送至API网关12，由API网关12将API请求发送至存储有相应服务对象的后端服务器14中。

在一可选实施例中，本申请的鉴权服务器13中的权限模型可以包括权限名称以及与权限名称对应的权限信息，不包括上下文信息。但是需要维护上下文信息与权限模型的对应关系，本申请实施例提供但不限于以下维护方式，如表2所示的表格，利用表格维护权限模型(例如权限名称)与上下文信息的对应关系。

表2权限名称与上下文信息的对应关系

权限名称	上下文信息
		开机	针对主机1进行开机操作
开机	针对主机1以及主机2进行开机操作
		关机	针对主机1进行关机操作
修改	要修改的主机1的内容
		升级	针对主机2进行升级操作
升级	针对主机3进行升级操作

如表2所示，可选的，可以在权限模型之外设置至少一个表格，若权限名称与上下文信息的对应关系改变，无需改变权限模型，仅需要变更上下文信息与权限模型的对应关系即可，从而使得权限模型更为简单。例如，若针对主机4进行开机操作也需要进行权限验证，则仅需将表2所示的表格增加一行(例如底色为灰色的一行)变为表3即可，无需更改权限名称“开机”对应的权限模型。

表3权限名称与上下文信息的对应关系

当然，上述表格仅为一种可选的示例，除此之外还可以通过其他方式实现维护权限名称与上下文信息的对应关系的目的，例如设置函数关系等。

需要说明的是，上述权限名称与上下文信息的对应关系还可以设置在权限模型中。

若本申请的鉴权服务器13中的权限模型包括权限名称以及与权限名称对应的权限信息，不包括上下文信息，那么鉴权服务器13接收到目标权限名称、上下文信息和用户标识后，可以基于目标权限名称获得目标权限模型，基于权限名称与上下文信息的对应关系，获得目标权限名称对应的目标上下文信息，若目标上下文信息包括鉴权服务器13接收到的上下文信息，则从目标权限模型中获取目标权限名称对应的目标权限信息；获取用户标识对应的用户角色，获取用户角色对应的权限信息，若用户角色对应的权限信息与目标权限名称对应的目标权限信息相同，则确定鉴权成功，否则鉴权失败。

前述本申请实施例中详细介绍了目标API模型包含与第一参数对应的目标权限名称的情况。可以理解的是，目标API模型中可能不包含与第一参数对应的目标权限名称，则若目标API模型不包含与第一参数对应的目标权限名称，表征无需验证权限，因此可以直接确定鉴权成功。

可选的，确定若目标API模型是否包含与第一参数对应的目标权限名称可以包括至少两种情况，接下来分别介绍。

第一种情况，API模型包括所需权限函数(上述示例的API模型2中，required_permissions即为所需权限函数)，各个权限名称设置在所需权限函数中，该所需权限函数用于管理各个权限名称。则本申请实施例可以基于目标API模型是否包含所需权限函数来确定目标API模型是否包含与第一参数对应的目标权限名称，即，可以首先遍历目标API模型来查看是否包含该所需权限函数，若目标API模型不包含所需权限函数，则表征目标API模型不包含与第一参数对应的目标权限名称；若目标API模型包含所需权限函数，则可以进一步遍历该所需权限函数来查看其是否包含与第一参数对应的目标权限名称，若不包含，则表征目标API模型不包含与第一参数对应的目标权限名称。

第二种情况，API模型不包括所需权限函数，各个权限名称未设置在一个函数中。本申请实施例可以直接遍历目标API模型，来查看其是否包含与第一参数对应的目标权限名称，若不包含，则表征目标API模型不包含与第一参数对应的目标权限名称。

综上，若目标API模型不包含与第一参数对应的目标权限名称，则API网关12可以直接确定鉴权成功，而无需将API请求携带的第一参数发送至鉴权服务器13，减少了鉴权服务器13的工作量。

在一可选实施例中，上述实施例提及的“从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称”的实现方式可以有多种，例如通过遍历查找API模型中的目标权限名称、通过二分查找API模型中的目标权限名称(若目标API模型可以对第一参数按照一定顺序排序，例如若第一参数首字母为英文，则按照“a”至“z”的顺序排序)等。本申请以遍历的方式为例进行说明，则上述C1(或D1)，从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称的过程具体可以包括：

E1、遍历所述目标API模型包含的至少一个权限名称分别对应的限制条件，一个权限名称对应的限制条件包括与该权限名称对应的参数需要满足的条件。

在一可选实施例中，一个权限名称对应的限制条件可以包括与该权限名称对应的参数的值需要满足的条件。

上述限制条件可以包括多种方式，本申请提供但不限于以下几种：

第一种，限制条件可以包括基本条件，这里基本条件至少可以包括：大于、等于、小于以及存在。

具体可以参见上述示例的API模型2，其中constraint表示限制条件，可选的，限制条件可以为一个基本条件eq即“等于”，示例的API模型2包含的三个限制条件分别用于：判断API请求携带的参数action的值是否等于start或stop或restart。

第二种，限制条件可以包括复合条件，这里复合条件至少可以包括以下至少一种：与“and”、或“or”以及非“not”。

例如，API请求携带的参数1的值“not”restart“and”参数2的值“not”start。

第三种，限制条件可以包括基本条件与复合条件的组合。

例如，API请求携带的参数1的值“eq”start且参数2的值“eq”up且参数3的值“not”0。

本步骤可以通过遍历的方式查找目标API模型包含的至少一个权限名称分别对应的限制条件；可选的，可以通过从前往后的方式遍历查找，还可以通过从后往前的方式遍历查找。

E2、若所述第一参数满足至少一个权限名称分别对应的限制条件中的目标限制条件，获取所述目标限制条件对应的所述目标权限名称。

仍以上述示例的API模型2为例，若API请求携带的第一参数的值等于start，或者restart，那么第一参数满足"eq":{"ref":{"context":{"name":"action","source":"body"}},value":"start"}这一限制条件，或者，满足"eq":{"ref":{"context":{"name":"action","source":"body"}},"value":"restart"}这一限制条件。那么目标权限名称为startVM。

若API请求携带的第一参数的值等于stop，那么第一参数满足"eq":{"ref":{"context":{"name":"action","source":"body"}},"value":"stop"}这一限制条件。那么目标权限名称为stopVM。

可选的，若第一参数不满足任意一个权限名称分别对应的限制条件中的目标限制条件，则无需验证权限。

可选的，若该API模型不包含限制条件，则说明无需验证权限。

综上，本申请实施例通过遍历目标API模型包含的至少一个权限名称分别对应的限制条件，得到目标限制条件，并基于该目标限制条件得到对应的目标权限名称，提高了查找目标限制条件对应的目标权限名称的效率。

上述本申请实施例详细介绍了应用于API网关12的权限模型获取方法，除此之外，本申请还公开了一种应用于鉴权服务器13的鉴权方法，接下来，对本申请公开的应用于鉴权服务器13的鉴权方法进行详细说明，该过程具体可以包括：

步骤F1、获取应用程序编程接口API网关发送的目标权限名称。

其中，所述目标权限名称是所述API网关确定的与第一参数对应的权限名称，所述第一参数是待鉴权的API请求中携带的用户标识和第一上下文信息中的至少一种。

由前述实施例介绍可知，API网关12可以接收终端11发送的API请求，进而可以基于API请求携带的至少第一参数，得到与第一参数对应的目标权限名称，并发送至鉴权服务器13。则本步骤中，鉴权服务器13可以接收API网关12发送的目标权限名称。

上述第一参数为终端11生成的待鉴权的API请求中携带的参数，该第一参数可以包括用户标识和第一上下文信息中的至少一种。

步骤F2、从多个权限模型中，获得所述目标权限名称对应的目标权限模型。

鉴权服务器13上或独立于鉴权服务器13设置的数据库15中存储有多个权限模型，则本步骤可以基于目标权限名称，从多个权限模型中，获取与该目标权限名称对应的目标权限模型。

可选的，上述任一个权限模型至少可以包括权限名称以及与权限名称对应的权限信息，则本申请可以基于从API网关12得到的目标权限名称，得到与其对应的目标权限模型。

可选的，上述任一个权限模型还可以包括权限名称、与权限名称对应的权限信息以及上下文信息。

步骤F3、基于所述目标权限模型，对所述API请求进行鉴权。

可选的，本申请中，鉴权服务器13还可以包括用户标识绑定的用户角色，以及用户角色对应的一个或多个权限信息。则本步骤至少可以基于目标权限模型中目标权限名称对应的权限信息，以及鉴权服务器13接收到的API请求携带的用户标识对应用户角色具有的权限信息，对API请求进行鉴权。

本申请提供的应用于鉴权服务器的鉴权方法，权限模型至少可以包括权限名称以及与权限名称对应的权限信息，并且权限名称与权限模型为一一对应的关系，即一个权限名称仅对应一个权限模型。则对于鉴权服务器而言，接收到的API网关发送的权限名称不同，得到的权限模型就不同，即在鉴权服务器中不是基于URL获得相应的权限模型，而是基于权限名称得到相应的权限模型，使得在鉴权服务器中构建权限模型时，由于不必做到权限模型与API请求的URL一致，所以不需要考虑是针对哪个API请求的，也无需构建相应的API请求。对于API网关而言，与目前权限定义只能是API级别不同，可以基于API请求中携带的参数定义权限，即使是同一API请求，其携带的参数不同，需要验证该API请求的权限模型可能相同可能不同，即构建一个API请求后，也无需必须构建一个与之对应的权限模型，例如可以与其他API请求共用一个权限模型，只要验证的权限信息一致就可以，从而使得权限模型与API请求解耦合，即API请求与权限模型不再必须是一一对应的关系。使得构建的API请求相对于目前而言较少，便于管理。

在一可选实施例中，若目标权限模型仅包括权限名称以及与权限名称对应的权限信息，则鉴权服务器13可以基于接收到的API请求携带的用户标识确定该用户标识对应的用户角色，并确定该用户角色对应的权限信息，若用户标识对应用户角色具有的权限信息与目标权限模型中目标权限名称对应的权限信息相同，则确定鉴权成功，否则鉴权失败。

在另一可选实施例中，本申请还可以获取API网关12发送的目标参数，该目标参数包括用户标识和第二上下文信息中的至少一种，并且该目标参数具有预设格式。由于目标参数具有预设格式，因此鉴权服务器13可以基于目标参数，对API请求进行鉴权，保证了可以完成鉴权过程，而不会出现无法鉴权的情况。

在又一可选实施例中，目标权限模型还可以包括权限名称、与权限名称对应的权限信息以及目标上下文信息，这里目标上下文信息与上述权限模型中包括的上下文信息对应，所不同的是，该目标上下文信息是指与目标权限名称对应的目标权限模型中包括的上下文信息。

若上述目标参数包括用户标识以及第二上下文信息，则上述步骤F3，基于所述目标权限模型，对所述API请求进行鉴权的过程具体可以包括：

G1、获取所述目标权限模型包含的权限信息。

前述已经说明了，API网关12可以获取API请求携带的第一参数对应的目标权限名称，该目标权限名称可以对应数据库15中存储的一个目标权限模型。可以理解的是，该目标权限模型中可能包括一个或多个权限信息，则本步骤可以获取目标权限模型中包含的权限信息。

G2、从预构建的权限模型与上下文信息关联关系中，获取目标权限模型对应的目标上下文信息。

由上述实施例中介绍可知，本申请可以预先构建权限名称与上下文信息的对应关系，例如表2或表3所示对应关系，而本申请权限名称与权限模型一一对应，因此权限模型与上下文信息也存在对应关系，则本步骤可以从权限模型与上下文信息存在的对应关系中，得到目标权限模型对应的目标上下文信息。

参见表2或表3，目标权限模型对应的目标上下文信息可能有多个。

G3、若所述第二上下文信息与所述目标上下文信息匹配，且，所述用户标识对应用户角色具有的权限信息与所述目标权限模型包含的权限信息匹配，确定鉴权成功。

这里，第二上下文信息与目标上下文信息匹配是指，可以理解的是，目标权限模型中可能对应多个目标上下文信息，则可选的，只要目标上下文信息中至少一个上下文信息与第二上下文信息相同，则确定第二上下文信息与目标上下文信息匹配。

用户标识对应用户角色具有的权限信息与目标权限模型包含的权限信息匹配是指，用户标识对应用户角色具有的权限信息与目标权限模型中目标权限名称对应的权限信息相同。

上述本申请公开的实施例中详细描述了方法，对于本申请的方法可采用多种形式的装置实现，因此本申请还公开了一种装置，下面给出具体的实施例进行详细说明。

参见图4，为本申请实施例公开的API网关的一种实现方式的结构示意图。

如图4所示，该API网关可以包括：

获取模块41，用于获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

转换模块42，用于将所述第三参数转换为具有预设格式的目标参数；

发送模块43，用于至少将所述目标参数发送至鉴权服务器。

在一可选实施例中，上述API请求还携带有表征API模型的属性标识的第二参数，上述转换模块可以包括：

模型获取单元，用于根据预先构建的多个API模型，获取所述第二参数对应的目标API模型；

确定单元，用于从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；

赋值单元，用于基于所述目标绑定规则，将所述第三参数的值赋值给具有所述预设格式的所述目标参数。

在一可选实施例中，上述API请求携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；

上述确定单元可以包括：

第一获取单元，用于从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称；

第二获取单元，用于获取所述目标权限名称对应的目标绑定规则。

在一可选实施例中，上述API请求携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；

还可以包括：

目标权限名称获取单元，用于从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称；

发送单元，用于至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据；

其中，一个API模型包含的不同权限名称对应不同的权限模型。

在一可选实施例中，还可以包括：

鉴权单元，用于若所述目标API模型不包含与所述第一参数对应的权限名称，确定鉴权成功。

在一可选实施例中，上述目标权限名称获取单元可以包括：

第一遍历单元，用于遍历所述目标API模型包含的至少一个权限名称分别对应的限制条件，一个权限名称对应的限制条件包括与该权限名称对应的参数需要满足的条件；

目标权限名称获取子单元，用于若所述第一参数满足至少一个权限名称分别对应的限制条件中的目标限制条件，获取所述目标限制条件对应的所述目标权限名称。

在一可选实施例中，上述确定单元可以包括：

第二遍历单元，用于遍历所述目标API模型包含的至少一个绑定规则；

确定子单元，用于将包含所述第三参数的绑定规则，确定为所述目标绑定规则。

在一可选实施例中，上述第二参数可以包括：待访问服务对象的URL统一资源定位符、提交方式信息，所述提交方式信息用于表征发送所述API请求的客户端与存储所述待访问服务对象的服务器的交互方式。

参见图5，为本申请实施例提供的API网关的设备硬件结构框图，API网关12的硬件结构可以包括：至少一个处理器51，至少一个通信接口52，至少一个存储器53和至少一个通信总线54；

在本申请实施例中，处理器51、通信接口52、存储器53、通信总线54的数量为至少一个，且处理器51、通信接口52、存储器53通过通信总线54完成相互间的通信；

处理器51可能是一个中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路等；

存储器53可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatilememory)等，例如至少一个磁盘存储器；

其中，存储器53存储有程序，处理器51可调用存储器53存储的程序，所述程序用于：

获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

将所述第三参数转换为具有预设格式的目标参数；

至少将所述目标参数发送至鉴权服务器。

可选的，所述程序的细化功能和扩展功能可参照上文描述。

本申请实施例还公开了一种应用于应用程序编程接口API网关12的可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时，实现如上述应用于应用程序编程接口API网关12的数据获取方法。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置或系统类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种数据获取方法，其特征在于，应用于应用程序编程接口API网关，包括：

获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

将所述第三参数转换为具有预设格式的目标参数；

至少将所述目标参数发送至鉴权服务器；

所述API请求还携带有表征API模型的属性标识的第二参数，所述将所述第三参数转换为具有预设格式的目标参数，包括：

根据预先构建的多个API模型，获取所述第二参数对应的目标API模型；从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；基于所述目标绑定规则，将所述第三参数的值赋值给具有所述预设格式的所述目标参数；

所述API请求携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；所述从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，包括：从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称；获取所述目标权限名称对应的目标绑定规则。

2.根据权利要求1所述数据获取方法，其特征在于，所述API请求携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；

还包括：

从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称；

至少将所述目标权限名称发送至鉴权服务器，所述目标权限名称是所述鉴权服务器获得用于验证所述API请求的权限模型的依据；

其中，一个API模型包含的不同权限名称对应不同的权限模型。

3.根据权利要求2所述数据获取方法，其特征在于，还包括：

若所述目标API模型不包含与所述第一参数对应的权限名称，确定鉴权成功。

4.根据权利要求1至3任一所述数据获取方法，其特征在于，所述从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称，包括：

遍历所述目标API模型包含的至少一个权限名称分别对应的限制条件，一个权限名称对应的限制条件包括与该权限名称对应的参数需要满足的条件；

若所述第一参数满足至少一个权限名称分别对应的限制条件中的目标限制条件，获取所述目标限制条件对应的所述目标权限名称。

5.根据权利要求1所述数据获取方法，其特征在于，所述从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，包括：

遍历所述目标API模型包含的至少一个绑定规则；

将包含所述第三参数的绑定规则，确定为所述目标绑定规则。

6.根据权利要求1至3任一所述数据获取方法，其特征在于，所述第二参数包括：待访问服务对象的URL统一资源定位符、提交方式信息，所述提交方式信息用于表征发送所述API请求的客户端与存储所述待访问服务对象的服务器的交互方式。

7.一种应用程序编程接口API网关，其特征在于，包括：

获取模块，用于获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

转换模块，用于将所述第三参数转换为具有预设格式的目标参数；

发送模块，用于至少将所述目标参数发送至鉴权服务器；

所述API请求还携带有表征API模型的属性标识的第二参数，所述转换模块，具体用于根据预先构建的多个API模型，获取所述第二参数对应的目标API模型；从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；基于所述目标绑定规则，将所述第三参数的值赋值给具有所述预设格式的所述目标参数；其中，所述API请求携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；所述从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，包括：从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称；获取所述目标权限名称对应的目标绑定规则。

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

存储器，用于存储程序；

处理器，用于执行所述程序，所述程序具体用于：

获取API请求，所述API请求至少携带有第三参数，所述第三参数包括用户标识和第二上下文信息中的至少一种；

将所述第三参数转换为具有预设格式的目标参数；

至少将所述目标参数发送至鉴权服务器；

所述API请求还携带有表征API模型的属性标识的第二参数，所述将所述第三参数转换为具有预设格式的目标参数，包括：根据预先构建的多个API模型，获取所述第二参数对应的目标API模型；从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，所述目标绑定规则包括所述第三参数与所述目标参数的对应关系；基于所述目标绑定规则，将所述第三参数的值赋值给具有所述预设格式的所述目标参数；

所述API请求携带有第一参数，所述第一参数包括用户标识和第一上下文信息中的至少一种；所述从所述目标API模型包含的至少一个绑定规则中，确定目标绑定规则，包括：从所述目标API模型包含的至少一个权限名称中，获取与所述第一参数对应的目标权限名称；获取所述目标权限名称对应的目标绑定规则。

9.一种可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上述权利要求1至6任一所述的数据获取方法包含的各个步骤。

Images