CN103841134B - 基于api发送、接收信息的方法、装置及系统 - Google Patents

Abstract

本申请公开了一种基于API发送、接收信息的方法、装置及系统，该方法包括：客户端确定终端用户的操作请求对应的服务API；根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息，确定客户端本地保存的参数值上下文中是否记载所述服务API的API参数对应的参数值；当客户端本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求；接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。能够较好地提高API更新的实时性，节省处理资源。

Description

基于API发送、接收信息的方法、装置及系统

技术领域

本申请涉及信息处理技术领域，尤其涉及一种基于应用程序编程接口（API，Application Programming Interface）发送、接收信息的方法、装置及系统。

背景技术

随着网络技术的快速发展，网络服务器能够通过终端为终端用户提供越来越多的业务。实际应用中，服务器为终端用户提供应用业务的方式，主要采用在终端安装并运行具有指定功能的客户端应用程序（以后简称客户端）的方式为终端用户提供应用业务，该客户端能够实现服务器向终端提供的业务。客户端在运行的过程中，主要通过与服务端（其中，服务端设置在服务器中）约定的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参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务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接收信息的装置，包括：接收单元，用于接收客户端在确定出本地保存的参数值上下文中，未记载服务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接口字典，在客户端向服务端发送API服务请求时，若无法在参数值上下文中获取构建API服务请求所需的API参数的参数值时，可以在API接口字典中，根据所述参数值的获取路径向服务端发送依次调用参数值获取路径中的API的请求，并接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。相对现有技术中客户端只能基于当前版本支持的API和属性信息与服务端进行通信，导致API服务请求失败的情况，以及更新API以及属性信息的过程中不能够发送API服务请求的情况，本方案能够实时获取更新后的API以及相应的属性信息对应的API参数的参数值以构建API服务请求，从而避免了API服务请求失败以及不能够发送API服务请求的情况，能够较好地提高客户端进行API更新的实时性，节省处理资源。

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

附图说明

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

图1为本申请实施例一中，提出的基于API发送信息的方法流程示意图；

图2为本申请实施例一中，提出的基于API发送信息的装置结构组成示意图；

图3为本申请实施例二中，提出的基于API接收信息的方法流程示意图；

图4为本申请实施例二中，提出的基于API接收信息的装置结构示意图；

图5为本申请实施例三中，提出的基于API系统结构组成示意图；

图6为本申请实施例三中，提出的基于API发送、接收信息的方法流程示意图；

图7为本申请实施例三中，提出的客户端动态获取参数值的方法流程示意图。

具体实施方式

针对现有技术中存在的在对API进行更新后，客户端需要占用资源下载相关更新的数据包，API更新实时性较差，并且客户端在进行API下载更新过程中导致客户端不可使用的问题，本申请实施例这里提出的技术方案，通过在服务端提供API接口字典，客户端根据API接口字典，向服务端发送API服务请求，服务端根据接收到的信息请求执行相应处理。

下面将结合各个附图对本申请实施例技术方案的主要实现原理、具体实施方式及其对应能够达到的有益效果进行详细地阐述。

需要说明的是，客户端可以是安装在终端中的程序或软件。其中，终端可以是移动终端、网路终端等。较佳地，本申请实施例这里将以移动终端为例来进行详细阐述。服务端可以设置在服务器中，例如计费服务器、内容服务器以及应用服务器等等，本申请实施例这里以应用服务器为例来进行详细阐述。

实施例一

本申请实施例一这里提出一种基于API发送信息的方法，如图1所示，具体处理过程如下：

步骤11，客户端接收终端用户发来的操作请求，并确定与该终端用户操作对应的服务API。

其中，终端用户通过操作来启动安装在移动终端中的客户端，在客户端启动后，终端用户操作客户端发起操作指令。

步骤12，客户端确定与终端用户的操作请求对应的服务API后，根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息。

其中，API接口字典记载服务API的属性信息。API接口字典可以是一个文本，以XML或者Json的格式存在，并且API接口字典中包含的内容可以根据实际需求进行扩展。所述的API接口字典可以包括服务端针对所述客户端设置的最新的API的属性信息。所述属性信息包括API参数及其参数值获取路径。

API参数包括输入参数和输出参数。本申请实施例一这里提出的技术方案中，根据所述属性信息中的API参数可以获得调用该服务API所需的输入参数的类型，以及调用该服务API后返回值所属的输出参数的类型。

参数值获取路径包括一个或多个服务API的调用顺序。其中，参数值获取路径可以根据各服务API之间的参数关系生成。对于某个指定参数的参数值，可以通过调用参数值获取路径中的一个或多个服务API而从服务端获得的返回值来确定。参数值获取路径根据各服务API之间的参数关系生成。

对于某些API参数的参数值，可以从本地记录中获取；对于另外一些API参数，则可以根据各服务API之间的参数关系以指定的服务API的返回值作为其参数值。

具体地，如果客户端需要请求某一服务API，则在API接口字典中可以获得调用该服务API时需要的属性信息。例如，假设客户端确定与终端用户的操作请求对应的服务API为API 5，在接口字典中保存的API 5的API参数（例如输入参数）的参数值获取路径是API2-API 3-API 5。由此可知，调用API 5之前，需要依次调用API 2、API 3。

此外，在API接口字典中，还可以但不限于包括下述几项信息：API名称，也可以称之为接口名称；例如API 1、API 5等等；及接口属性，例如域名信息等。

其中，API接口字典可以是服务端提供，也可以是在客户端本地保存的。

在从API接口字典中确定与所述服务API对应的属性信息时可以先检查服务端的API接口字典是否有更新。

当服务端的API接口字典没有更新时，所述的属性信息可以从客户端本地保存的API接口字典获取，也可以通过预先设定的API接口从服务端的API接口字典中获取。

当服务端的API接口字典有更新时，客户端可以通过预先设定的API接口将服务端的API接口字典更新到本地的API接口字典，所述的属性信息从客户端本地保存的API接口字典获取；所述的属性信息也可以从服务端当前提供的最新API接口字典中获取。

具体实施中，当API接口字典保存在客户端时，则在根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息之前，还可以包括：客户端判断本地保存的API接口字典与所述服务端当前提供的API接口字典是否一致，在确定出不一致时，下载服务端当前提供的API接口字典并保存在本地。

步骤13，根据客户端本地保存的用于存储与所述属性信息中的API参数对应的参数值的参数值上下文，判断是否记载所述服务API的API参数对应的参数值，如果判断结果为是，执行步骤14，反之执行步骤15。

其中，参数值上下文保存在客户端本地，用于保存每个服务API的API参数和参数值的对应关系。

步骤14，获得所述服务API的API参数对应的参数值，并根据获得的参数值构建API服务请求，并将该API服务请求发送给服务端，请求进行相应的操作。

其中，当在参数值上下文中能够获得构建API服务的API参数对应的参数值时，则根据获得的参数值构建API服务请求并将构建的API服务请求发送给服务端。构建API服务请求并发送该API服务请求给服务端的方法流程与现有技术中基本相同，这里不再赘述。

步骤15，在参数值上下文中获取相应的参数值时，当客户端本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，在API接口字典中，获得参数值获取路径。

步骤16，客户端根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求。

需要说明的是，参数值获取路径中包含的一个或多个服务API的调用顺序，均可以作为独立的服务API，也可以是获得构建API服务请求所需的API参数的参数值获取路径中的一个。即参数值获取路径可以是一个服务API，也可以是多个服务API组成的队列，例如，可以包括3个服务API：API 1、API2及API 3。客户端可以根据所述参数值获取路径中包含的服务API队列，顺序地逐一地向所述服务端发送API参数值获取请求。

在根据参数值获取路径获得参数值时，客户端向服务端发送依次调用参数值获取路径中的API的请求，服务端接收到参数值获取路径中包含的第一个API服务请求（设为API1）之后，返回值(假设为M2)给客户端。客户端在接收到与API 1对应的返回值（M2）之后，会将返回值M2作为参数值获取路径中包含的第二个API服务请求（设为API_2）的参数值，构建API_2服务请求再发送给所述服务端；所述服务端正确的响应API_2服务请求，并返回值（设为M3）给所述客户端，以此类推，直到最后所述客户端接收到所述服务端发来的路径终点的返回值，将该返回值作为获得的参数值。

步骤17，客户端接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。

其中，接收所述服务端发送的返回值之后，还可以包括：确定接收的返回值和所述服务API的API参数之间的对应关系，并将所述对应关系保存在参数值上下文中。其中，API参数和参数值的对应关系在参数值上下文中保存时，可以永久保存，也可以是临时保存。具体可以根据API参数和参数值的重要程度以及开发人员对其所做的约定来实现。

相应地，本申请实施例一这里还提出一种基于API发送信息的装置，如图2所示，包括：

第一确定单元201，用于确定终端用户的操作请求对应的服务API。

第二确定单元202，用于根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序。

判断单元203，用于确定客户端本地保存的参数值上下文中是否记载所述服务API的API参数对应的参数值。

发送单元204，用于当客户端本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求。

具体地，所述参数值获取路径根据各服务API之间的参数关系生成。

接收单元205，用于接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。

其中，上述装置还可以包括：

保存单元，用于判断本地保存的API接口字典与所述服务端当前提供的API接口字典是否一致，在确定出不一致时，下载服务端当前提供的API接口字典并保存在本地。

应当理解，以上装置包括的单元仅为根据该装置实现的功能进行的逻辑划分，实际应用中，可以进行上述单元的叠加或拆分。并且该实施例提供的装置所实现的功能与上述实施例提供的基于API发送信息的方法流程一一对应，对于该装置所实现的更为详细的处理流程，在上述方法实施例中已做详细描述，此处不再详细描述。

实施例二

本申请实施例二这里提出一种基于API接收信息的方法，如图3所示，具体处理过程如下：

步骤31，服务端接收客户端发来的依次调用参数值获取路径中的API的请求。

其中，客户端在确定出本地保存的参数值上下文中，未记载服务API的API参数对应的参数值时，根据记载服务API属性信息的API接口字典，发来的依次调用参数值获取路径中的API的请求，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序。

步骤32，服务端根据参数值获取路径中的API的请求，依次向客户端发送返回值。

具体地，客户端根据所述参数值获取路径中的API队列，顺序地逐一地向所述服务端发送API的请求。其中，服务端接收到参数值获取路径中第一个API属的请求后，发送返回值给客户端。客户端在接收到服务端对第一个API的请求的返回值后，会将返回值作为参数值获取路径中第二个API的请求的参数值，通过第二个API服务请求再发给所述服务端；所述服务端正确的响应第二个API参数值获取请求，并返回参数值给所述客户端；以此类推，直到最后所述客户端接收到所述服务端发来的路径信息终点的参数值。

步骤33，服务端接收客户端根据所述返回值构建的API服务请求并执行处理。

其中，所述API服务请求是客户端确定出与终端用户的操作请求对应的服务API后构建的。

可选地，在步骤31之前，还可以包括：服务端在确定出API信息更新后，更新所述API接口字典。具体地，服务端通过监听API文本，在确定出API有更新时，更新API接口字典。

具体地，上述所述参数值获取路径根据各服务API之间的参数关系生成。

相应地，本申请实施例二这里还提出一种基于API接收信息的装置，如图4所示，该装置包括：

接收单元401，用于接收客户端在确定出本地保存的参数值上下文中，未记载服务API的API参数对应的参数值时，根据记载服务API属性信息的API接口字典，发来的依次调用参数值获取路径中的API的请求，其中，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序。

具体地，所述参数值获取路径根据各服务API之间的参数关系生成。

发送单元402，用于根据参数值获取路径中的API的请求，依次向客户端发送返回值。

所述接收单元401，还用于接收客户端根据所述返回值构建的API服务请求并执行处理，其中，所述API服务请求是客户端确定出与终端用户的操作请求对应的服务API后构建的。

其中，上述装置还可以包括：

更新单元，用于在确定出API接口字典有更新时，更新API接口字典。

应当理解，以上装置包括的单元仅为根据该装置实现的功能进行的逻辑划分，实际应用中，可以进行上述单元的叠加或拆分。并且该实施例提供的装置所实现的功能与上述方法实施例提供的基于API接收信息的的方法流程一一对应，对于该装置所实现的更为详细的处理流程，在上述方法实施例中已做详细描述，此处不再详细描述。

实施例三

进一步地，本申请实施例三这里在上述实施例一和实施例二的基础之上，将客户端基于API发送信息和服务端基于API接收信息作为一个整体的流程，来详细阐述本申请这里提出的基于API发送信息和接收信息的方法，如图5所示，本申请实施例这里提出一种基于API的系统，该系统包括客户端和服务端，其中：

客户端，安装在终端中，例如安装在移动终端中、也可以是网络终端等等。用于确定终端用户的操作请求对应的服务API；根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序；确定客户端本地保存的参数值上下文中是否记载所述服务API的API参数对应的参数值；当本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求；接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。

服务端，用于接收客户端在确定出本地保存的参数值上下文中，未记载服务API的API参数对应的参数值时，根据记载服务API属性信息的API接口字典，发来的依次调用参数值获取路径中的API的请求，其中，所述属性信息包括API参数及其参数值获取路径，根据参数值获取路径中的API的请求，依次向客户端发送返回值；以及接收客户端根据所述返回值构建的API服务请求并执行处理。

基于图5所示的系统架构，本申请实施例三这里，以客户端在发送信息请求过程中动态更新API接口字典为例，来进一步详细阐述基于API发送信息请求和服务端基于API接收信息请求的方法。

需要说明的是，本申请实施例三这里将以终端用户通过操作移动终端上安装的客户端，向服务端发送购买商品并使用优惠券进行付款的一系列操作为例，来进一步详细阐述本申请实施例这里提出的技术方案。如图6所示，具体流程如下：

步骤601，终端用户通过操作来启动安装在移动终端中的客户端。

步骤602，客户端启动后，客户端通过和服务端进行通信，判断API接口字典是否有更新。如果判断结果为是，则执行步骤603，反之，执行步骤604。

其中，API接口字典可以保存在服务端。API接口字典记载服务API的属性信息。API接口字典可以是一个文本，以XML或者Json的格式存在，并且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接口字典的版本号为V1.0并保存在本地，相隔一段时间之后，服务端通过监听API接口文档的变化，服务端中保存的API接口字典已经更新过两次，版本号变为V1.2，则此时若终端用户启动客户端，客户端在启动运行后，通过与服务端进行通信，比对API接口字典的版本号，发现本地保存的API接口字典的版本号V1.0与服务单当前发布的API接口字典版本号V1.2不同，则确定服务端发布的API接口字典有更新，反之，则确定服务端发布的API接口字典没有更新。

具体地，本申请实施例三这里，服务端保存的API接口字典中的信息可以是卖家的优惠信息，例如将优惠券的编码信息存储在API接口字典中。较佳地，为保证电子商务中买家和卖家的安全性，该些优惠券的编码信息进行保密处理。服务端通过监听API接口文档的变化，来对保存的API接口字典进行更新。例如，一些卖家在特殊时段提供的优惠信息等等。

步骤603，客户端判断出本地保存的API接口字典与服务端当前提供的API接口字典二者的版本号不一致，则在服务端中学习服务端当前提供的API接口字典并保存在本地。

例如，服务端当前提供的API接口字典中新增加了卖家提供的优惠信息21，API接口字典版本号更新为V1.1，移动终端本地保存的API接口字典的版本号为V1.0，则确定API接口字典不一致，需要进行更新。

步骤604，客户端判出断本地保存的API接口字典与服务端当前提供的API接口字典相同，则不需要更新本地保存的API接口字典。此时，客户端接收终端用户发来的操作指令。

步骤605，客户端确定与终端用户的操作请求对应的服务API后，根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息。

步骤606，根据确定的属性信息，根据客户端本地保存的用于存储与所述属性信息中的API参数对应的参数值的参数值上下文，确定所述服务API的API参数对应的参数值。

其中，上述步骤604~步骤606中，假设终端用户在移动终端中的客户端上进行操作，发送操作指令，客户端收到操作指令后，需要向服务端发起的API服务请求为API_1。则客户端需要构建API_1服务请求，构建API_1服务请求需要确定对应的API参数为P_a，则客户端在本地保存的参数值上下文中获取对应的参数值，本申请实施例三这里假设参数值为11，并且该参数值11在参数值上下文中能够获取到，即在移动终端中存储的参数值上下文中存储有参数值11。

具体地，假设终端用户在移动终端中的客户端上进行操作，发送操作指令，客户端收到操作指令后，需要向服务端发起的API服务请求为API_1。则客户端需要构建API_1服务请求，构建API_1服务请求需要确定对应的API参数为P_a（本申请实施例四这里假设P_a为终端用户的用户名），则客户端在本地保存的参数值上下文中获取对应的参数值，本申请实施例三这里假设为P_a对应的参数值为11（本申请实施例三这里假设11为终端用户名对应的数值），并且该参数值11在参数值上下文中能够获取到，即在移动终端中存储的参数值上下文中存储有参数值11。

步骤607，客户端根据获取到的参数值，构建API服务请求，并将构建的API服务请求发送至服务端。

例如，客户端根据获取到的参数值11，构建的API服务请求为API_1，将API_1发送至服务端请求进行处理。具体地，客户端根据获取到的终端用户的用户名对应的数值11，构建API_1服务请求发送给服务端，用于请求购买商品XXX。

步骤608，服务端在接收到客户端发送的API_1服务请求之后，进行相应的处理，并在处理结果中加入属性信息P_B，然后将处理结果反馈给客户端，指示客户端进行下一步处理。

具体地，服务端在接收到客户端发送的用于购买商品XXX的API_1服务请求之后，进行相应的处理，并在处理结果中加入属性信息P_B（本申请实施例四这里假设P_B是生成购买商品XXX的订单号），服务端将包含订单号的处理结果反馈给客户端。

步骤609，客户端接收到服务端反馈的处理结果，对反馈结果进行解析，根据解析结果继续向服务端发送API服务请求。

例如，客户端接收到服务端反馈结果，并对反馈结果进行解析，将订单号在移动终端上展示给终端用户，同时将订单号对应的参数值保存在移动终端本地。

步骤610，客户端接收到终端用户发来的对订单进行处理的操作请求，此时客户端需要构建API_2服务请求发送给服务端，但是假设构建API_2服务请求的是需要API参数P_B和P_C对应的参数值12和13，客户端在参数值上下文中查找参数值值12和参数值13。

需要说明的是，本申请实施例三这里为了详细阐述客户端在发送信息请求的过程中动态更新API接口字典的方法流程，假设参数值上下文中没有存储P_C和对应的参数值13。

具体地，终端用户根据在移动终端展示的购买商品XXX的订单号，对客户端进行操作，发起付款请求。此时，如果商家有优惠信息，例如店铺会员可以减免费用等，并提供减免费用的优惠券信息，该信息保存在API接口字典中。假设终端用户可以使用该优惠信息，即此时，终端用户对客户端进行操作，请求使用优惠券信息进行付款以完成订单。此时，客户端需要构建API_2服务请求（即本申请实施例四这里提出的使用优惠券信息完成付款的请求）发送给服务端，但是构建API_2服务请求的条件是需要P_B（订单号）和P_C（优惠券信息）对应的参数值12（订单号对应的参数值值）和13（优惠券信息对应的参数值），客户端在参数值上下文中查找参数值12和参数值13。

步骤611，客户端在参数值上下文中获取了P_B对应的参数值12，但是没有获取到P_C对应的参数值13，则客户端需要在本地保存的API接口字典中确定用于获取参数值13的参数值获取路径，假设参数值13的参数值获取路径为API_3，则客户端发起API_3服务请求，请求获取参数值13。

具体地，客户端在参数值上下文中获取了P_B（订单号）对应的参数值12，但是没有获取到P_C（优惠券信息）对应的参数值13，则客户端需要在本地保存的API接口字典中确定用于获取参数值13的参数值获取路径，假设参数值获取路径为API_3，则客户端发起API_3服务请求（即本申请实施例三这里提出的获取优惠券信息的请求），请求获取参数值13（优惠券信息对应的参数值值）。

步骤612，服务端接收到客户端发来的API_3服务请求，对API_3服务请求进行处理，查找参数值13，并将查找到的参数值13反馈给客户端。

步骤613，客户端接收服务端发来的参数值13，将参数值13保存在参数值上下文中，然后客户端根据参数值12和参数值13构建API_2服务请求，发送给服务端。

例如，客户端接收服务端发来的参数值13（优惠券信息的参数值），将参数值13保存在参数值上下文中，然后客户端根据参数值12(订单号)和参数值13（优惠券信息）构建API_2服务请求，发送给服务端，完成付款。

步骤614，服务端接收到客户端发来的API_2服务请求，进行处理，并反馈相应的处理结果。例如，向客户端反馈付款成功的信息。

步骤615，客户端接收到服务端反馈的处理结果后，结束操作。例如，客户端接收到服务端反馈的处理结果之后，展示给终端用户，告知终端用户本次交易成功。

其中，在上述步骤603中，客户端确定出需要对本地保存的API接口字典进行更新时，假设在服务端保存的API接口字典中，开发人员对API_3服务请求对应的属性信息进行了更新，增加了一个新的API参数P_D（例如，卖家又增加了一个优惠券信息，为便于阐述，称之为第二优惠券信息），并设定其对应的参数值14，并且参数值14的参数值获取路径为API_1-----API_4，即先要调用API_1服务请求，再发送API_4服务请求，才能获得参数值14，然后根据获得的参数值14构建API_3服务请求发送给服务端。如图7所示，客户端通过顺序调用API参数值获取路径中的API队列，在服务端中获得参数值的具体流程如下，这里仍然以买家购买商品为例进行详细阐述：

步骤6031，终端用户在移动终端上对安装的客户端进行操作，客户端根据接收到的终端用户进行的操作，确定对应的API服务请求为API_3，则需要构建API_3服务请求。

例如，终端用户获知卖家对商品XXX在原先优惠信息（为便于阐述，简称为第一优惠券信息）的基础之上，又增加了新的优惠券信息（第二优惠券信息），则终端用户选择卖家提供的双层优惠来完成订单的支付。终端用户在客户端上进行相应的操作，发送选择双层优惠来完成订单。

步骤6032，由于构建API_3服务请求客户端在移动终端本地保存的参数值上下文中，获取API_3对应的API参数P_D（卖家提供的第二个优惠券信息）的参数值14，但是由于移动终端本地保存的参数值上下文中并没有参数值14，此时，需要构建API_4服务请求发送给服务端获取参数值14（即卖家提供的第二优惠券信息）。

步骤6033，由于API接口字典中记载的获取参数值14的参数值14的获取路径为API_1---API_4，此时客户端需要构建并发送API_1服务请求、API_4服务请求给服务端，请求获取参数值14。

其中，客户端在参数值上下文中获取构建API_1服务请求的P_a对应的参数值11，然后构建API_1服务请求发送给服务端。

为保证信息的安全性，防止不法分子的侵入，本申请实施例三这里提出的技术方案中，在卖家获取第二优惠信息时，需要使用自身的用户名，即客户端需要构建并发送API_1服务请求给服务端，请求获取参数值14（即第二优惠信息的参数值），即告知服务端谁需要获得什么。

步骤6034，服务端对接收到的客户端发来的API_1服务请求进行处理，将处理成功的反馈信息给客户端，其中，在反馈信息中携带有P_D对应的参数值14。

服务端对接收到的的API_1服务请求进行处理，例如对终端用户的身份进行验证等，验证通过之后，将携带第二优惠信息对应的参数值的反馈信息发送给客户端。

步骤6035，客户端对接收到的服务端发来的反馈信息进行解析，获得反馈信息中携带的P_D对应的参数值14，将参数值14保存在参数值上下文中。

客户端将获得的第二优惠信息对应的参数值保存在参数值上下文中。其中，参数值的保存方式可以但不限于是永久性存储或者是暂时性存储。例如，对于涉及终端用户的用户名的参数值可以永久性存储在参数值上下文中，而对于有时限的优惠信息，可以选择暂时性存储。

步骤6036，客户端根据获得的参数值14继续构建API_3服务请求，并将API_3服务请求发送给服务端。

客户单根据获得的第二优惠信息的参数值14继续构建完成订单API_3服务请求，并发送给服务端。

步骤6037，服务端对接收到客户端发来的API_3服务请求进行处理，并反馈处理结果给客户端。

步骤6038，客户端接收到服务端对API_3服务请求处理后反馈的结果，确定API接口字典更新成功。

采用本申请实施例三这里提出的技术方案，客户端可以根据服务端当前发布的API接口字典构建API服务请求，当客户端根据API对应的API参数的参数值在参数值上下文中获取参数值时，若参数值上下文中不存在相应的参数值，客户端可以从API接口字典中获取API参数值获取路径，相对现有技术中客户端只能基于当前版本支持的API以及属性信息与服务端进行通信，导致API服务请求失败的情况，以及更新API以及属性信息的过程中不能够发送API服务请求的情况，本方案能够实时获取更新后的API以及相应的属性信息对应的参数值以构建并发送API信息请求，从而避免了API服务请求失败以及不能够发送API服务请求的情况。并且，在实际应用中，为保证信息传输的安全性，还可以将选择至少一个API做出约定，使得每次发送API服务请求时，都必须要先执行做出约定的API服务请求，从而，较好的实现了API动态部署和升级，实时性较好，不需要占用终端处理资源从服务端下载相应的更新信息。

本领域的技术人员应明白，本申请的实施例可提供为方法、装置（设备）、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

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

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

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (10)

1.一种基于应用程序编程接口API发送信息的方法，其特征在于，包括：

客户端确定终端用户的操作请求对应的服务API；

根据记载服务API的属性信息的API接口字典，确定与所述服务API对应的属性信息，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序；

确定客户端本地保存的参数值上下文中是否记载所述服务API的API参数对应的参数值；

当客户端本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求；

接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。

2.如权利要求1所述的方法，其特征在于，所述参数值获取路径根据各服务API之间的参数关系生成。

3.如权利要求1所述的方法，其特征在于，所述API接口字典保存在客户端；

在根据记载服务API的属性信息的API接口字典中，确定与所述服务API对应的属性信息之前，还包括：

客户端判断本地保存的API接口字典与所述服务端当前提供的API接口字典是否一致，在确定出不一致时，下载服务端当前提供的API接口字典并保存在本地。

4.一种基于应用程序编程接口API接收信息的方法，其特征在于，包括：

服务端接收客户端在确定出本地保存的参数值上下文中，未记载服务API的API参数对应的参数值时，根据记载服务API属性信息的API接口字典，发来的依次调用参数值获取路径中的API的请求，其中，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序；

服务端根据依次调用参数值获取路径中的API的请求，依次向客户端发送返回值；以及

服务端接收客户端根据所述返回值构建的API服务请求并执行处理，其中，所述API服务请求是客户端确定出与终端用户的操作请求对应的服务API后构建的。

5.如权利要求4所述的方法，其特征在于，所述参数值获取路径根据各服务API之间的参数关系生成。

6.一种基于应用程序编程接口API发送信息的装置，其特征在于，包括：

第一确定单元，用于确定终端用户的操作请求对应的服务API；

第二确定单元，用于根据记载服务API的属性信息的API接口字典，确定与所述服务API对应的属性信息，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序；

判断单元，用于确定客户端本地保存的参数值上下文中是否记载所述服务API的API参数对应的参数值；

发送单元，用于当客户端本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求；

接收单元，用于接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端。

7.如权利要求6所述的装置，其特征在于，所述参数值获取路径根据各服务API之间的参数关系生成。

8.一种基于应用程序编程接口API接收信息的装置，其特征在于，包括：

接收单元，用于接收客户端在确定出本地保存的参数值上下文中，未记载服务API的API参数对应的参数值时，根据记载服务API属性信息的API接口字典，发来的依次调用参数值获取路径中的API的请求，其中，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序；

发送单元，用于根据依次调用参数值获取路径中的API的请求，依次向客户端发送返回值；

所述接收单元，还用于接收客户端根据所述返回值构建的API服务请求并执行处理，其中，所述API服务请求是客户端确定出与终端用户的操作请求对应的服务API后构建的。

9.如权利要求8所述的装置，其特征在于，所述参数值获取路径根据各服务API之间的参数关系生成。

10.一种基于应用程序编程接口API的系统，其特征在于，包括客户端和服务端，其中：

所述客户端，用于确定终端用户的操作请求对应的服务API；根据记载服务API的属性信息的API接口字典，确定与所述服务API对应的属性信息，所述属性信息包括API参数及其参数值获取路径，所述参数值获取路径包括一个或多个服务API的调用顺序；确定客户端本地保存的参数值上下文中是否记载所述服务API的API参数对应的参数值；当本地保存的参数值上下文中未记载所述服务API的API参数对应的参数值时，根据所述参数值获取路径向服务端发送依次调用参数值获取路径中的API的请求；接收所述服务端的返回值，并根据返回值构建与所述服务API对应的API服务请求并发送至服务端；

服务端，用于接收客户端在确定出本地保存的参数值上下文中，未记载服务API的API参数对应的参数值时，根据记载服务API属性信息的API接口字典，发来的依次调用参数值获取路径中的API的请求，其中，所述属性信息包括API参数及其参数值获取路径，根据依次调用参数值获取路径中的API的请求，依次向客户端发送返回值；以及接收客户端根据所述返回值构建的API服务请求并执行处理。