CN106936937B - 用于互联网业务交互的通用接口的实现方法和装置 - Google Patents

Abstract

本申请提出一种用于互联网业务交互的通用接口的实现方法和装置，该用于互联网业务交互的通用接口的实现方法包括：位于服务端的通用接口接收客户端发送的通用入参；所述通用接口根据通用入参确定需要调用的业务服务端及业务服务端需要的入参；所述通用接口分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参；所述通用接口对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端。该方法能够在实现新功能时不需要客户端升级，并且可以降低客户端与服务端的交互次数，节省网络流量。

Description

用于互联网业务交互的通用接口的实现方法和装置

技术领域

本申请涉及互联网技术领域，尤其涉及一种用于互联网业务交互的通用接口的实现方法和装置。

背景技术

在互联网的业务交互中，客户端和服务端的交互方式是通过远程过程调用(Remote Procedure Calls，RPC)接口来完成，需要实现一个功能，目前通用的做法是：首先，服务端定义接口名称及相应参数；其次，通过RPC客户端接口插件生成对应的客户端代码，集成到客户端中；再次，如果要实现上线，则必须要进行客户端升级。

由于一个接口调用意味着一次网络交互，往往一个完整的功能会有多次的接口调用，意味着多次的网络交互，对网络要求很高。

发明内容

本申请旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的一个目的在于提出一种用于互联网业务交互的通用接口的实现方法，该方法可以在实现新功能时不需要客户端升级，并且可以降低客户端与服务端的交互次数，节省网络流量。

本申请的另一个目的在于提出一种用于互联网业务交互的通用接口的实现装置。

为达到上述目的，本申请第一方面实施例提出的用于互联网业务交互的通用接口的实现方法，包括：位于服务端的通用接口接收客户端发送的通用入参；所述通用接口根据通用入参确定需要调用的业务服务端及业务服务端需要的入参；所述通用接口分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参；所述通用接口对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端。

本申请第一方面实施例提出的用于互联网业务交互的通用接口的实现方法，通过位于服务端的通用接口从不同的业务服务端获取业务参数并进行转换后发送给客户端，客户端只需要与通用接口交互，由通用接口与不同的业务服务端进行交互，从而在实现新功能时，可以由通用接口调用新的接口，不需要客户端升级，并且由于不需要客户端与每个业务服务端分别进行交互，可以降低客户端与服务端的交互次数，节省网络流量。

为达到上述目的，本申请第二方面实施例提出的用于互联网业务交互的通用接口的实现装置，所述装置位于服务端，所述装置包括：接收模块，用于接收客户端发送的通用入参；确定模块，用于根据通用入参确定需要调用的业务服务端及业务服务端需要的入参；交互模块，用于分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参；发送模块，用于对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端。

本申请第二方面实施例提出的用于互联网业务交互的通用接口的实现装置，通过位于服务端的通用接口从不同的业务服务端获取业务参数并进行转换后发送给客户端，客户端只需要与通用接口交互，由通用接口与不同的业务服务端进行交互，从而在实现新功能时，可以由通用接口调用新的接口，不需要客户端升级，并且由于不需要客户端与每个业务服务端分别进行交互，可以降低客户端与服务端的交互次数，节省网络流量。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1是本申请一实施例提出的用于互联网业务交互的通用接口的实现方法的流程示意图；

图2是本申请另一实施例提出的用于互联网业务交互的通用接口的实现方法的流程示意图；

图3是本申请另一实施例提出的用于互联网业务交互的通用接口的实现装置。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的模块或具有相同或类似功能的模块。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。相反，本申请的实施例包括落入所附加权利要求书的精神和内涵范围内的所有变化、修改和等同物。

图1是本申请一实施例提出的用于互联网业务交互的通用接口的实现方法的流程示意图，该方法包括：

S11：位于服务端的通用接口接收客户端发送的通用入参。

其中，在需要实现某项业务功能时，客户端可以向服务端发送接口请求，接口请求中包含入参，以便服务端根据入参获取出参并返回给客户端，客户端根据出参实现相应功能。

通常一个功能需要调用多个服务端的接口，传统方案中，客户端分别与每个接口对应的业务服务端进行交互，从而在新定义一个接口后，需要客户端升级以获知新的接口，另外，由于客户端需要与每个接口对应的业务服务端进行交互，也会加大网络流量开销。

本实施例中，可以在服务端设置通用接口，客户端向通用接口发送接口请求，接口请求中包含通用入参。

通用入参的格式可以如表1所示。

表1

S12：通用接口根据通用入参确定需要调用的业务服务端及业务服务端需要的入参。

通用接口在接收到客户端发送的通用入参后，可以根据配置中心的配置确定需要调用的业务服务端及对应的入参。

配置中心可以预先配置在数据库中，并缓存在服务端。

例如，通用入参中可以包括规则，配置中心可以配置规则与需要调用的业务服务端及需要的入参之间的对应关系，因此，通用接口接收到通用入参后，可以根据其中的规则以及配置中心配置的上述的对应关系，确定出需要调用的业务服务端及对应的需要的入参。

S13：通用接口分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参。

例如，确定出需要调用的业务服务端包括：业务服务端A和业务服务端B，相应的需要的入参包括：入参_1和入参_2，则可以将入参_1发送给业务服务端A，将入参_2发送给业务服务端B，假设业务服务端A根据入参_1得到的业务出参是出参_1，业务服务端B根据入参_2得到的业务出参是出参_2，则通用接口可以分别接收业务服务端A发送的出参_1以及业务服务端B发送的出参_2。

业务出参的格式可以参见表2。

表2

S14：通用接口对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端。

假设所有需要调用的业务服务端包括业务服务端A和业务服务端B，则通用接口在接收到业务服务端A发送的出参_1和业务服务端B发送的出参_2后，可以将出参_1和出参_2转换为通用出参，并发送给客户端。

在转换时，根据实际情况的不同，可以是将所有的业务服务端发送的出参进行汇总后发送给客户端，如将出参_1和出参_2一起发送给客户端，或者，如果后一个业务服务端的需要的入参包括前面业务服务端的出参，如业务服务端B需要的入参包括业务服务端A的业务出参，则返回给客户端的通用出参是业务服务端B的业务出参。

相对的，传统方案中需要客户端分别与业务服务端A交互，从业务服务端A获取出参_1，以及与业务服务端B交互，从业务服务端B获取出参_2。

本实施例中，通过位于服务端的通用接口从不同的业务服务端获取业务参数并进行转换后发送给客户端，客户端只需要与通用接口交互，由通用接口与不同的业务服务端进行交互，从而在实现新功能时，可以由通用接口调用新的接口，不需要客户端升级，并且由于不需要客户端与每个业务服务端分别进行交互，可以降低客户端与服务端的交互次数，节省网络流量。

图2是本申请另一实施例提出的用于互联网业务交互的通用接口的实现方法的流程示意图，该方法包括：

S21：客户端向位于通用接口发送接口请求，接口请求中包含通用入参。

接口请求例如用于请求通用接口。

通用入参中例如包括规则(rule)。

S22：通用接口根据通用入参中的规则从配置中心，确定需要调用的业务服务端及业务服务端需要的入参。

其中，配置中心可以预先配置规则与业务服务端及需要的入参之间的对应关系，因此，根据该对应关系可以确定需要调用的业务服务端及需要的入参。

对应关系的格式可以如表3所示。

表3

例如，需要调用的业务服务端包括：mobilecashier和mobilepayfront。

需要的入参例如包括：action。

另外，如表3所示的，需要调用的业务服务端可以指明调用方式。

调用方式例如包括：是独立调用还是顺序调用，例如，需要调用的业务服务端包括业务服务端A和业务服务端B，则可以表明是分别独立调用业务服务端A和业务服务端B，或者，也可以表明是先调用业务服务端A再调用业务服务端B。

在分别独立调用业务服务端时，每个业务服务端分别有各自需要的入参及相应的业务出参，之后通用接口可以将不同的业务服务端的业务出参进行汇总后一起发送给客户端。

在有先后顺序调用的方式中，可以默认或指明后续调用的业务服务端需要的入参包括前面调用的业务服务端的业务出参，例如，在指明业务服务端A和业务服务端B是先后顺序调用时，业务服务端B需要的入参可以默认或指明包括业务服务端A的业务出参。此时，通用接口可以将最后调用的业务服务端的业务出参返回给客户端。

本实施例以先调用mobilecashier再调用mobilepayfront为例，且mobilepayfront需要的入参包括mobilecashier的出参。

S23：通用接口向mobilecashier发送mobilecashier需要的入参，以及接收mobilecashier发送的业务出参。

S24：通用接口向mobilepayfront发送mobilepayfront需要的入参，以及接收mobilepayfront发送的业务出参。

例如，mobilepayfront需要的入参包括mobilecashier发送的业务出参。

mobilepayfront发送的业务出参包括mobilepayfront的业务出参。

S25：通用接口将mobilepayfront的业务出参发送给客户端。

例如，通过透传方式将出参发送给客户端。

本实施例中，通过通用接口与不同的业务服务端进行交互，可以避免客户端与每个业务服务端的交互，因此，在实现新功能时，不需要客户端升级，由通用接口进行调用并将出参返回给客户端，另外，还可以降低客户端与服务端交互的次数，降低网络流量开销。

图3是本申请另一实施例提出的用于互联网业务交互的通用接口的实现装置，该装置位于服务端，该装置30包括：接收模块31、确定模块32、交互模块33和发送模块34。

接收模块31，用于接收客户端发送的通用入参；

其中，在需要实现某项业务功能时，客户端可以向服务端发送接口请求，接口请求中包含入参，以便服务端根据入参获取出参并返回给客户端，客户端根据出参实现相应功能。

通常一个功能需要调用多个服务端的接口，传统方案中，客户端分别与每个接口对应的业务服务端进行交互，从而在新定义一个接口后，需要客户端升级以获知新的接口，另外，由于客户端需要与每个接口对应的业务服务端进行交互，也会加大网络流量开销。

本实施例中，可以在服务端设置通用接口，客户端向通用接口发送接口请求，接口请求中包含通用入参。

通用入参的格式可以如表1所示。

确定模块32，用于根据通用入参确定需要调用的业务服务端及业务服务端需要的入参；

可选的，所述通用入参中包括规则，所述确定模块32具体用于：

从配置中心获取规则与需要调用的业务服务端及需要的入参之间的对应关系；

根据所述对应关系，确定与接收的通用入参中包括的规则对应的需要调用的业务服务端及需要的入参。

通用接口在接收到客户端发送的通用入参后，可以根据配置中心的配置确定需要调用的业务服务端及对应的入参。

配置中心可以预先配置在数据库中，并缓存在服务端。

例如，通用入参中可以包括规则，配置中心可以配置规则与需要调用的业务服务端及需要的入参之间的对应关系，因此，通用接口接收到通用入参后，可以根据其中的规则以及配置中心配置的上述的对应关系，确定出需要调用的业务服务端及对应的需要的入参。

交互模块33，用于分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参；

例如，确定出需要调用的业务服务端包括：业务服务端A和业务服务端B，相应的需要的入参包括：入参_1和入参_2，则可以将入参_1发送给业务服务端A，将入参_2发送给业务服务端B，假设业务服务端A根据入参_1得到的业务出参是出参_1，业务服务端B根据入参_2得到的业务出参是出参_2，则通用接口可以分别接收业务服务端A发送的出参_1以及业务服务端B发送的出参_2。

业务出参的格式可以参见表2。

发送模块34，用于对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端。

假设所有需要调用的业务服务端包括业务服务端A和业务服务端B，则通用接口在接收到业务服务端A发送的出参_1和业务服务端B发送的出参_2后，可以将出参_1和出参_2转换为通用出参，并发送给客户端。

在转换时，根据实际情况的不同，可以是将所有的业务服务端发送的出参进行汇总后发送给客户端，如将出参_1和出参_2发送给客户端，或者，如果后一个业务服务端的需要的入参包括前面业务服务端的出参，如业务服务端B需要的入参包括业务服务端A的业务出参，则返回给客户端的通用出参是业务服务端B的业务出参。

相对的，传统方案中需要客户端分别与业务服务端A交互，从业务服务端A获取出参_1，以及与业务服务端B交互，从业务服务端B获取出参_2。

一些实施例中，所述交互模块33具体用于：如果确定出的业务服务端是按照先后顺序调用的，且排序在后的业务服务端的需要的入参包括排序在前的业务服务端的业务出参，则依序向每个业务服务端发送需要的入参，并在接收到排序在前的业务服务端的业务出参后向排序在后的下一个业务服务端发送需要的入参，所述需要的入参包括排序在前的业务服务端的业务出参；

相应的，所述发送模块34具体用于：将排序在最后的业务服务端的业务出参作为通用出参，发送给客户端，其中，排序在最后的业务服务端的业务出参中包括排序在前的业务服务端的业务出参。

例如，需要调用的业务服务端包括业务服务端A和业务服务端B，假设业务服务端A和业务服务端B存在先后顺序的调用关系，且业务服务端B需要业务服务端A的业务出参时，则需要先向业务服务端A发送业务服务端A需要的入参并接收业务服务端A返回的业务出参，之后再向业务服务端B发送业务服务端B需要的入参，且包括业务服务端A的业务出参。

之后，在向客户端发送通用出参时，将业务服务端B的业务出参返回给客户端。

一些实施例中，所述交互模块33具体用于：如果确定出的业务服务端的调用不存在先后顺序，则分别独立向每个业务服务端发送需要的入参并接收相应的业务出参；

相应的，所述发送模块34具体用于：对所有需要调用的业务服务端发送的业务出参进行汇总；以及，将汇总得到的业务出参作为通用出参发送给客户端。

例如，需要调用的业务服务端包括业务服务端A和业务服务端B，假设业务服务端A和业务服务端B不存在先后顺序的调用关系，则可以分别独立向业务服务端A发送业务服务端A需要的入参并接收业务服务端A发送的业务出参，以及，向业务服务端B发送业务服务端B需要的入参并接收业务服务端B发送的业务出参。

之后，在向客户端发送通用出参时，将业务服务端A的业务出参及业务服务端B的业务出参一起返回给客户端。

本实施例中，通过位于服务端的通用接口从不同的业务服务端获取业务参数并进行转换后发送给客户端，客户端只需要与通用接口交互，由通用接口与不同的业务服务端进行交互，从而在实现新功能时，可以由通用接口调用新的接口，不需要客户端升级，并且由于不需要客户端与每个业务服务端分别进行交互，可以降低客户端与服务端的交互次数，节省网络流量。

需要说明的是，在本申请的描述中，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。此外，在本申请的描述中，除非另有说明，“多个”的含义是指至少两个。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

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

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

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

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (8)

1.一种用于互联网业务交互的通用接口的实现方法，其特征在于，包括：

位于服务端的通用接口接收客户端发送的通用入参；所述通用入参中包括规则，其中，每个规则指示了对应的功能的配置；

所述通用接口根据通用入参确定需要调用的业务服务端及业务服务端需要的入参，包括：从配置中心获取规则与需要调用的业务服务端及需要的入参之间的对应关系；根据所述对应关系，确定与接收的通用入参中包括的规则对应的需要调用的业务服务端及需要的入参；

所述通用接口分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参；

所述通用接口对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端。

2.根据权利要求1所述的方法，其特征在于，所述分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参，包括：

如果确定出的业务服务端是按照先后顺序调用的，且排序在后的业务服务端的需要的入参包括排序在前的业务服务端的业务出参，则依序向每个业务服务端发送需要的入参，并在接收到排序在前的业务服务端的业务出参后向排序在后的下一个业务服务端发送需要的入参，所述需要的入参包括排序在前的业务服务端的业务出参。

3.根据权利要求2所述的方法，其特征在于，所述对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端，包括：

将排序在最后的业务服务端的业务出参作为通用出参，发送给客户端，其中，排序在最后的业务服务端的业务出参中包括排序在前的业务服务端的业务出参。

4.根据权利要求1所述的方法，其特征在于，所述分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参，包括：

如果确定出的业务服务端的调用不存在先后顺序，则分别独立向每个业务服务端发送需要的入参并接收相应的业务出参。

5.根据权利要求4所述的方法，其特征在于，所述对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端，包括

对所有需要调用的业务服务端发送的业务出参进行汇总；

将汇总得到的业务出参作为通用出参发送给客户端。

6.一种用于互联网业务交互的通用接口的实现装置，其特征在于，所述装置位于服务端，所述装置包括：

接收模块，用于接收客户端发送的通用入参；所述通用入参中包括规则，其中，每个规则指示了对应的功能的配置；

确定模块，用于根据通用入参确定需要调用的业务服务端及业务服务端需要的入参；

交互模块，用于分别将每个业务服务端需要的入参发送给对应的业务服务端，并接收对应的业务服务端发送的根据需要的入参得到的业务出参；

发送模块，用于对所有需要调用的业务服务端发送的业务出参进行转换，得到通用出参，并将通用出参发送给客户端；

所述确定模块具体用于：

从配置中心获取规则与需要调用的业务服务端及需要的入参之间的对应关系；

根据所述对应关系，确定与接收的通用入参中包括的规则对应的需要调用的业务服务端及需要的入参。

7.根据权利要求6所述的装置，其特征在于，

所述交互模块具体用于：如果确定出的业务服务端是按照先后顺序调用的，且排序在后的业务服务端的需要的入参包括排序在前的业务服务端的业务出参，则依序向每个业务服务端发送需要的入参，并在接收到排序在前的业务服务端的业务出参后向排序在后的下一个业务服务端发送需要的入参，所述需要的入参包括排序在前的业务服务端的业务出参；

所述发送模块具体用于：将排序在最后的业务服务端的业务出参作为通用出参，发送给客户端，其中，排序在最后的业务服务端的业务出参中包括排序在前的业务服务端的业务出参。

8.根据权利要求6所述的装置，其特征在于，

所述交互模块具体用于：如果确定出的业务服务端的调用不存在先后顺序，则分别独立向每个业务服务端发送需要的入参并接收相应的业务出参；

所述发送模块具体用于：对所有需要调用的业务服务端发送的业务出参进行汇总；以及，将汇总得到的业务出参作为通用出参发送给客户端。

Images