业务请求的响应方法、装置及电子设备与流程

1.本公开涉及计算机技术领域，尤其涉及云计算平台领域。


背景技术：

2.实现中，客户端与服务器之间存在多种数据请求接口，通过多个数据请求接口，客户端实现与服务端的数据交互，进而实现客户端的不同应用。相关技术中，不同的数据请求接口，其响应格式存在不同，因此，客户端和服务端需要基于不同的响应格式，为不同的数据请求接口单独开发响应解析逻辑，需要耗费较大的开发成本。


技术实现要素：

3.本公开提供了一种业务请求的响应方法、装置及电子设备。
4.根据本公开的第一方面，提供了一种业务请求的响应方法，适用于服务器，所述方法包括：接收业务请求，并获取所述业务请求的属性信息和请求内容；根据所述请求内容，获取所述业务请求所请求的业务数据；根据所述业务数据和所述属性信息生成响应包，并将所述响应包发送至对应的客户端，其中，所述响应包中包括消息头和数据体，其中，所述消息头根据所述属性信息生成，所述数据体根据所述属性信息和所述业务数据生成。
5.根据本公开的第二方面，提供了一种业务请求的响应方法，适用于客户端，所述方法包括：向服务器发送业务请求，其中，所述业务请求包括属性信息和请求内容；接收所述服务器发送的所述业务请求的响应包，其中，所述响应消息包括中包括消息头和数据体，其中，所述消息头根据所述属性信息生成，所述数据体根据所述属性信息和所述业务数据生成；对所述响应包进行解包，以所述数据体中获取所述业务请求所请求的业务数据。
6.根据本公开的第三方面，提供了一种业务请求的响应装置，适用于服务器，所述装置包括：接收模块，用于接收业务请求，并获取所述业务请求的属性信息和请求内容；获取模块，用于根据所述请求内容，获取所述业务请求所请求的业务数据；生成模块，用于根据所述业务数据和所述属性信息生成响应包，并将所述响应包发送至对应的客户端，其中，所述响应包中包括消息头和数据体，其中，所述消息头根据所述属性信息生成，所述数据体根据所述属性信息和所述业务数据生成。
7.根据本公开的第四方面，提供了一种业务请求的响应装置，适用于客户端，所述装置包括：发送模块，用于向服务器发送业务请求，其中，所述业务请求包括属性信息和请求内容；接收模块，用于接收所述服务器发送的所述业务请求的响应包，其中，所述响应消息包括中包括消息头和数据体，其中，所述消息头根据所述属性信息生成，所述数据体根据所述属性信息和所述业务数据生成；解包模块，用于对所述响应包进行解包，以所述数据体中获取所述业务请求所请求的业务数据。
8.根据本公开的第五方面，提供了一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上
述第一方面和第二方面任一项所述的业务请求的响应方法。
9.根据本公开的第六方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行上述第一方面和第二方面任一项所述的业务请求的响应方法。
10.根据本公开的第七方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现上述第一方面和第二方面任一项所述的业务请求的响应方法。
11.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
12.附图用于更好地理解本方案，不构成对本公开的限定。其中：
13.图1为本公开一实施例的业务请求的响应方法的流程示意图；
14.图2为本公开另一实施例的业务请求的响应方法的流程示意图；
15.图3为本公开另一实施例的业务请求的响应方法的流程示意图；
16.图4为本公开另一实施例的业务请求的响应方法的流程示意图；
17.图5为本公开另一实施例的业务请求的响应方法的流程示意图；
18.图6为本公开另一实施例的业务请求的响应方法的流程示意图；
19.图7为本公开另一实施例的业务请求的响应方法的流程示意图；
20.图8为本公开一实施例的业务请求的响应装置的结构示意图；
21.图9为本公开另一实施例的业务请求的响应装置的结构示意图；
22.图10为本公开另一实施例的业务请求的响应装置的结构示意图；
23.图11为本公开另一实施例的业务请求的响应装置的结构示意图；
24.图12为本公开一实施例的电子设备的示意性框图。
具体实施方式
25.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
26.计算机技术(computer technology)，可分为计算机系统技术、计算机器件技术、计算机部件技术和计算机组装技术等几个方面。计算机技术包括：运算方法的基本原理与运算器设计、指令系统、中央处理器(cpu)设计、流水线原理及其在cpu设计中的应用、存储体系、总线与输入输出。是指计算机领域中所运用的技术方法和技术手段，或指其硬件技术、软件技术及应用技术。
27.云计算平台(cloud computing platform)，也称为云平台，是指基于硬件资源和软件资源的服务，提供计算、网络和存储能力。云计算平台可以划分为3类：以数据存储为主的存储型云平台，以数据处理为主的计算型云平台以及计算和数据存储处理兼顾的综合云计算平台。
28.图1为本公开一实施例的业务请求的响应方法的流程示意图，该方法适用于服务器，如图1所示，该方法包括：
29.s101，接收业务请求，并获取业务请求的属性信息和请求内容。
30.客户端可以通过与服务器的信息交互实现其自身设定的相关功能，其中，不同的功能需要通过相应的业务数据得以实现，因此，客户端需要基于不同的业务向服务器发送不同的业务请求，比如信息查询等等。
31.实现中，服务器与客户端之间存在至少一个业务接口，基于业务接口可以实现服务器与客户端之间的信息交互。
32.其中，为了可以通过业务接口实现信息交互，服务器和客户端之间存在响应逻辑，基于响应逻辑可以限定业务接口的响应格式，服务器可以根据设定的格式将需要进行交互的数据进行打包，并通过业务接口进行传输，从而达到信息交互的目的。
33.本公开实施例中，可以基于统一的响应逻辑对全部的业务接口的响应格式进行限定，使得不同的业务接口可以采用相同的响应格式。
34.进一步地，客户端基于统一的响应逻辑，通过业务接口将业务请求发送至服务器。服务器接收到业务需求后，可以从中提取所需的内容，包括其中的属性信息和请求内容。
35.其中，属性信息可以包括业务类型的标识、请求类型的标识、时间戳等等相关信息，请求内容为业务请求需要的详细业务数据的相关信息等等。
36.s102，根据请求内容，获取业务请求所请求的业务数据。
37.服务器基于获取到的业务请求，可以从其自身的业务数据存储位置中，调取客户端所需的业务数据。
38.可选地，可以基于请求内容实现业务数据的获取。根据客户端的功能设定不同功能对应的关键字，并在关键字与其对应的业务数据之间设定相应的映射关系。服务器在获取到业务请求中携带的关键字后，可以查询设定的映射关系，进而获取业务请求对应的业务数据。
39.s103，根据业务数据和属性信息生成响应包，并将响应包发送至对应的客户端，其中，响应包中包括消息头和数据体，其中，消息头根据属性信息生成，数据体根据属性信息和业务数据生成。
40.本公开实施例中，服务器获取到业务请求对应的业务数据后，需要将业务数据以及相关的属性信息进行打包，进而生成对应的响应包。
41.进一步地，可以基于统一的响应逻辑限定的响应格式进行数据打包生成对应的响应包，并发送至客户端。
42.可选地，可以基于客户端/服务器(client/server，c/s)协议对业务数据和属性信息进行打包，其中，响应包中包含数据体和消息头两个部分。
43.其中，基于服务器响应以及获取业务数据的相关属性信息，可以生成响应包中的消息头，可以理解为，消息头有设定的格式，可以基于属性信息中包括的内容，按照设定的格式生成统一的消息头。
44.进一步地，基于服务器获取到的业务数据的相关内容，可以生成响应包中的数据体，可以理解为，数据体具有设定的格式，可以基于业务数据和属性信息生成统一的数据体。
45.需要说明的是，统一的消息头和统一的数据体仅是格式上统一，具体取值在不同的业务类型是不同的。
46.进一步地，服务器将打包好的业务请求对应的响应包通过设定的业务接口传输至客户端。
47.本公开提出的业务请求的响应方法，服务器获取客户端发送的业务请求后，提取其中的属性信息和请求内容，根据请求内容获取相应的业务数据，并基于设定响应格式将服务器对业务请求的响应的相关属性信息以及获取到的业务数据进行打包，基于属性信息生成消息头，基于业务内容生成数据体，进而生成相应的响应包并传输给客户端。本公开中，对服务器和客户端之间的响应逻辑进行了统一，统一的响应逻辑对服务器进行数据打包的响应格式进行了限定，使得服务器基于相同的格式对不同业务接口对应的不同的业务数据进行打包，生成统一的响应格式的响应包，从而简化了服务器和客户端之间的数据交互过程，节省了客户端与服务器的开发时间，有效节约了开发资源。
48.上述实施例中，关于响应包的生成，可结合图2进一步理解，图2为本公开另一实施例的业务请求的响应方法的流程示意图，该方法适用于服务器，如图2所示，该方法包括：
49.s201，根据属性信息，对消息头中包括第一设定顺序的第一通用字段进行赋值，生成消息头。
50.本公开实施例中，服务器和客户端之间通过响应包实现数据交互，其中，服务器将业务请求对应的业务数据和属性信息进行打包生成响应包，客户端可以对响应包进行数据提取。
51.其中，响应包中存在基于属性信息生成的消息头，客户端可以通过消息头的字段内容获取服务器的响应状态。可选地，可以在消息头中设定固定的多个字段，通过对固定的字段的内容的读取，获取服务器响应的相关状态。进一步地，可以将这部分用于体现服务器响应的相关状态的固定字段确定为消息头中的第一通用字段。
52.实现中，响应格式中对于消息头中的第一通用字段设定了排列顺序，第一通用字段中的每个字段基于设定的排列顺序依次排列，则可以将该排列顺序确定为第一通用字段的第一设定顺序。
53.消息头中的第一通用字段限定了响应包可以传输的信息类型，进一步地，可以为第一通用字段进行赋值，并通过读取第一通用字段被赋值的内容，使得客户端可以获取到服务器的相关响应状态的详细内容。
54.进一步地，从属性信息中提取第一通用字段的配置参数。
55.本公开实施例中，第一通用字段的配置参数可以从属性信息中获取，服务器可以从属性信息中进行配置参数的提取，通过对配置参数对应的信息的读取，可以获取服务器响应的相关状态。因此，可以从属性信息的全部配置参数中，获取第一通用字段对应的配置参数，进而实现为第一通用字段的赋值。
56.可选地，可以提取第一通用字段中每个字段对应的关键字，并从属性信息包含的配置参数中进行关键字的提取，进而获取第一通用字段对应的配置参数。
57.进一步地，按照第一设定顺序，并基于第一通用字段的配置参数，对第一通用字段进行赋值，进而生成响应包中的消息头。
58.比如，设定响应包中消息头的第一通用字段包括status字段、msg字段、logid字
段、timestamp字段，则基于属性信息对第一通用字段进行赋值，则可以生成对应的消息头，如下所示：
59."status":0,
60."msg":"",
61."logid":"1760505286",
62."timestamp":"1553848923000",
63.其中，status字段、msg字段、logid字段、timestamp字段基于第一设定顺序排列。status字段、msg字段、logid字段、timestamp字段以及各个字段对应的内容，组成了本示例中响应包的消息头。
64.进一步地，在消息头中，通过status字段的取值，可以确定服务器响应状态，由示例可知，当前响应包中status字段的取值为0，则可以判断当前服务器对客户端的业务请求的响应成功。
65.msg字段的可以是文字，该字段的内容可以理解为，对于响应状态的补充文字说明，若status字段的取值为非0，则msg字段可以对status字段的不同取值进行补充说明，比如status字段取值为1时，msg字段可以为用户不存在，再比如status字段取值为2时，msg字段可以为服务器状态异常等等。
66.logid字段的取值为业务请求的标识信息，基于该标识信息可以实现相关数据的定位。
67.timestamp字段的取值内容为服务器对业务请求的接收以及响应对应的时间。
68.其中，可以获取业务请求的响应状态，根据响应状态对第一通用字段中的目标通用字段进行赋值。
69.实现中，服务器会将对业务请求的响应状态打包至响应包中，其中，可以将消息头中用于体现服务器的响应状态的字段确定为目标通用字段，并基于属性信息中该字段的配置参数为目标通用字段赋值。客户端基于响应包中该字段的赋值内容，即可获取服务器对于业务请求的响应状态。
70.依然以上述示例为例，其中，status字段即为目标通用字段，基于属性信息为其赋值为0，如下所示：
71."status":0,
72."msg":"",
73.可选地，属性信息中对服务器响应状态正常的配置参数可以设定为0，则基于属性信息中status字段对应的配置参数，可以为该字段赋值为0，客户端可以基于该赋值判断当前服务器对客户端的业务请求的响应成功。
74.再比如，基于属性信息为status字段赋值为1，如下所示：
75."status":1,
76."msg":"用户不存在",
77.可选地，属性信息中对服务器响应状态异常的配置参数可以设定为非0，不同的参数取值可以指代不同的异常状态。比如，可以将用户不存在对应的异常状态的配置参数设定为1，则当服务器进行数据获取时发现该类型的异常状态时，可以基于属性信息中status字段对应的配置参数，为该字段赋值为1，客户端基于该赋值即可确定当前服务器响应状态
异常。
78.进一步地，为了可以更加详细的获取异常的具体情况，可以为status字段体现的异常情况进行补充说明。可选地，可以通过msg字段实现。msg字段可以是补充的文字内容，当status字段赋值为1时，属性信息中msg字段对应的配置参数即为对1的补充说明，则基于属性信息中该字段的配置参数，将msg字段赋值为用户不存在。
79.s202，根据业务数据和属性信息，对数据体中包括第二设定顺序的第二通用字段和数组进行填充，生成数据体。
80.本公开实施例中，服务器可以基于业务请求对应的业务数据和相关的属性信息进行打包，生成响应包中的数据体。
81.其中，数据体中可以存在多个固定字段，通过设定的固定字段可以限定响应包中数据体可以传输的信息类型，并将该部分固定字段确定为数据体的第二通用字段。
82.进一步地，第二通用字段存在设定的排列顺序，第二通用字段基于设定的排列顺序依次排列。其中，可以将该设定的排列顺序确定为第二设定顺序。
83.其中，从属性信息中提取业务请求的业务类型标识。
84.实现中，服务器可以从属性信息中提取业务类型标识，不同的业务类型标识属于不同的业务接口，服务器基于不同的业务类型标识，可以确定响应包返回客户端的业务接口。
85.可选地，可以将每个业务接口与其对应的业务类型标识之间构建连接关系，服务器从属性信息中提取业务类型标识后，基于构建的连接关系，即可确定响应包返回对应的业务接口。
86.设定，业务类型标识为name时，对应的业务接口为接口a，则当响应包中数据体如下所示时：
[0087][0088]
其中，data字段、business字段、actions字段以及各个字段对应的内容，即为本示例中响应包的数据体。
[0089]
进一步地，在数据体中，data字段可以作为消息头和数据体之间的分隔字段，data
字段的内容即为服务器基于客户端发送的业务请求打包的数据体的详细内容。
[0090]
其中，business字段为业务请求的标识信息，基于该字段的内容可以使得客户端确定处理响应包中的业务数据的业务层。actions字段的内容即为下一层的详细数据，确定业务数据对应的标识信息后，通过actions字段的内容即可获取相应的业务层需要处理的具体业务数据，并基于actions字段中的内容实现客户端的相关功能。
[0091]
其中，从第二通用字段中的business字段可知，上述数据体对应的业务类型标识为name，则可以判断，上述数据体对应的响应包可以从接口a返回客户端。
[0092]
进一步地，按照第二设定顺序，基于业务类型标识对第二通用字段进行赋值，并将业务数据写入数组中，以生成数据体。
[0093]
本公开实施例中，第二通用字段中的字段基于第二设定顺序排列，服务器从属性信息中提取到第二通用字段的参数后，可以基于第二设定顺序，依次对第二通用字段进行赋值。
[0094]
进一步地，可以将业务请求对应的业务数据以数组的形式写入数据体，客户端基于数据体中数组内容的部分，获取业务请求对应的详细业务数据。
[0095]
比如，服务器获取到的业务请求对应的业务数据为xxx，其业务类型标识为city，则基于第二设定顺序对第二通用字段进行赋值后，将xxx写入业务数据对应的数组，则可以生成如下所示的数据体：
[0096][0097]
其中，business字段、actions字段基于第二设定顺序排列。
[0098]
可选地，通过business字段的赋值可以获取业务类型标识，由上述示例可知，服务器从属性信息中获取本次业务请求对应的业务类型city，并将其赋值于business字段。
[0099]
可选地，可以将业务请求对应的详细业务数据写入actions字段下的数组中，如上述示例所示，服务器基于业务请求获取对应的业务数据为xxx，则将该数据写入数组中。
[0100]
进一步地，将赋值后的第二通用字段以及数组基于第二设定顺序排列，进而生成相应的数据体。
[0101]
s203，对消息头和数据体打包生成响应包。
[0102]
本公开实施例中，响应包中包含消息头和数据体两个部分，在分别生成消息头和数据体后，可以将二者基于响应格式进行排列，进而生成业务请求对应的响应包。
[0103]
在上述示例的基础上，基于消息头和数据体生成的响应包，可以如下所示：
[0104][0105]
其中，由status字段可知服务器响应状态正常，则msg字段赋值为空，logid字段赋值为业务请求对应的定位字符，timestamp字段赋值为服务器响应业务请求对应的时间戳，data字段中为响应包中的数据体部分，通过business字段的赋值可知客户端发送的业务请求为城市类业务请求，服务器获取到的相应的业务数据为xxx，进一步地，生成业务请求对应的响应包，并通过对应的业务接口传输至客户端。
[0106]
需要说明的是，客户端可以基于不同类型的业务请求，通过任一个业务接口将业务请求传输至服务器，服务器可以通过任一个业务接口接收客户端发送的业务请求，并基于接收到的业务请求生成对应的响应包。可以理解为，业务接口a和业务接口b的响应包的格式与上述实施例中代码部分的格式相同，区别在于相同字段具有不同的值。比如，timestamp字段赋值为服务器响应业务请求对应的时间戳，接口a为1553848923000，接口b为1553848923000。
[0107]
本公开提出业务请求的响应方法，基于统一限定的响应格式，根据属性信息，对消息头中的第一通用字段按第一设定顺序进行赋值，生成对应的消息头。根据业务请求对应的业务数据以及属性信息，对数据体中的第二通用字段按第二设定顺序进行赋值，生成对
应的数据体。进一步地，基于消息头和数据体生成业务请求对应的响应包。本公开中，客户端和服务器可以统一响应解析逻辑，使得服务器可以基于统一的响应格式生成业务请求对应的响应包，进而使得客户端可以基于统一的响应逻辑实现响应包的解包，简化了服务器和客户端之间的数据交互过程，节省了客户端与服务器的开发时间，有效节约了开发资源。
[0108]
实现中，服务器和客户端之间统一了响应逻辑，则服务器可以基于统一的响应格式生成响应包，在服务器和客户端之间存在多个业务接口的场景中，每个业务接口均使用相同的响应逻辑。可以理解为，针对每个业务接口，通过对相同的字段进行不同的赋值，进而实现不同的业务接口对应的响应包的生成。不同的业务接口对应的响应包中，所使用的字段和字段之间的排列结构均是相同的。
[0109]
相应地，为了实现上述适用于服务器的业务请求的响应方法，本公开还提出一种适用于客户端的业务请求的响应方法，可结合图3进一步理解，图3为本公开另一实施例的业务请求的响应方法的流程示意图，如图3所示，该方法包括：
[0110]
s301，向服务器发送业务请求，其中，业务请求包括属性信息和请求内容。
[0111]
实现中，客户端的相关功能，需要依赖于服务器中的相关业务数据得以实现，因此，客户端可以将属性信息和请求内容写入业务请求，服务器提取业务请求中的属性信息和请求内容，生成对应的响应包，进而将客户端所需的业务数据返回。
[0112]
可选地，客户端可以基于设定的服务器和客户端之间的响应逻辑生成对应的业务请求，并通过任一个业务接口发送至服务器。
[0113]
s302，接收服务器发送的业务请求的响应包，其中，响应消息包括中包括消息头和数据体，其中，消息头根据属性信息生成，数据体根据属性信息和业务数据生成。
[0114]
本公开实施例中，服务器可以基于客户端发送的业务请求，生成对应的响应包，并通过对应的业务接口将响应包发送至客户端。
[0115]
进一步地，客户端可以接受服务器返回的响应包。实现中，服务器和客户端之间存在设定的响应逻辑，服务器基于响应逻辑对其返回的业务数据和属性信息进行打包生成响应包，客户端可以基于设定的响应逻辑对响应包中的数据进行读取，并获取其中的消息头和数据体。
[0116]
其中，通过对消息头中第一通用字段的赋值的读取，可以确定本次业务数据获取过程中服务器响应的相关属性信息，比如响应成功、响应异常以及异常的具体原因等等。
[0117]
通过对数据体中第二通用字段的赋值的读取，可以获取本次业务请求返回的业务类型标识以及详细的业务数据。
[0118]
在上述示例的基础上可知，响应包中的消息头可以如下所示：
[0119]
"status":0,
[0120]
"msg":"",
[0121]
"logid":"1760505286",
[0122]
"timestamp":"1553848923000",
[0123]
客户端通过读取其中第一通用字段的赋值即可获取本次服务器对于客户端发送的业务请求响应的相关属性信息。
[0124]
响应包中的数据体可以如下所示：
[0125][0126]
则客户端通过读取其中第二通用字段的赋值，即可获取本次服务器对于客户端发送的业务请求返回的业务类型表示以及详细的业务数据。
[0127]
s303，对响应包进行解包，以数据体中获取业务请求所请求的业务数据。
[0128]
本公开实施例中，客户端接收到响应包后，可以基于服务器和客户端之间的响应逻辑对响应包进行解包处理，进而读取其中的消息头和数据体。
[0129]
依然如上述示例所示，服务器返回的业务类型为“name”，从actions字段中的内容获取业务请求对应的详细业务数据，如上述示例可知，本次服务器获取到的业务数据为％％％，客户端基于该字段中的数组内容即可获取到具体的业务数据％％％。
[0130]
本公开提出的业务请求的响应方法，基于设定的响应逻辑，客户端基于属性信息和请求内容生成业务请求发送服务器，并接收服务器返回的响应包，对响应包进行解包，读取响应包中的消息头和数据体，进而获取服务器本次对业务请求响应的相关属性信息以及具体的业务数据。本公开中，对客户端和服务器统一了响应逻辑，并基于统一的响应逻辑对响应格式进行了限定，使得服务器可以基于相同的响应格式，对不同业务接口对应的不同的业务数据进行打包，生成统一的响应格式的响应包，客户端可以基于统一的响应逻辑实现响应包的解包，从而简化了服务器和客户端之间的数据交互过程，节省了客户端与服务器的开发时间，有效节约了开发资源。
[0131]
作为一种可能，关于对响应包的解包，可结合图4进一步理解，图4为本公开另一实施例的业务请求的响应方法的流程示意图，该方法适用于客户端，如图4所示，该方法包括：
[0132]
s401，从响应消息进行解析出消息头和数据体。
[0133]
本公开实施例中，服务器和客户端之间存在设定的响应逻辑，服务器基于该设定的响应逻辑生成业务请求对应的响应包，因此，客户端可以基于该响应逻辑对响应包进行解包。
[0134]
可选地，响应逻辑可以基于c/s协议设定。
[0135]
进一步地，客户端接收到响应包后，基于设定的响应逻辑对响应包进行解包并读取其中的消息头和数据体。
[0136]
其中，消息头基于服务器对本次业务请求的响应的属性信息生成，数据体基于业务请求对应的业务类型标识和详细的业务数据生成。
[0137]
进一步地，客户端可以基于获取到的响应包实现其业务请求对应的功能。
[0138]
s402，对消息头中按序提取第一通用字段的参数值。
[0139]
本公开实施例中，客户端可以基于第一设定顺序读取响应包中的消息头中传输的信息，从而确定服务器对于业务请求响应的相关属性信息。
[0140]
其中，可以从消息头中第一通用字段赋值的参数值确定相关属性信息的具体内容。
[0141]
比如，从status字段的赋值，可以确定服务器本次对业务请求的响应是否成功。在上述示例的基础上可知，当客户端读取到的status字段的参数值为1时，可以判断本次对客户端发送的业务请求的响应出现异常，并通过msg字段的参数值确定异常的具体情况。
[0142]
实现中，第一通用字段中基于第一设定顺序排列，因此，客户端可以基于第一设定顺序按序依次对字段的参数值进行读取，进而获取每个字段对应的参数值。
[0143]
s403，响应于第一通用字段的参数值指示业务请求响应成功，从数据体中提取业务数据。
[0144]
本公开实施例中，通过对第一通用字段的参数值的读取，可以判断业务请求的响应是否成功。
[0145]
在上述示例的基础上可知，当客户端读取到的第一通用字段中的status字段的参数值为0时，可以判断服务器本次对客户端发送的业务请求的响应成功。
[0146]
客户端基于第一通用字段中的参数值的读取，可以确定本次服务器对客户端发送的业务请求响应成功，则可以判断，当前服务器返回客户端的响应包中的数据体中携带的业务数据是客户端业务请求所需的业务数据，进一步地，可以对数据体中的业务数据进行提取。
[0147]
其中，获取数据体中的第二通用字段的配置参数值，以获取业务请求的业务类型标识。
[0148]
本公开实施例中，客户端中存在多个业务层，每个业务层被设定可以处理不同的业务类型的业务数据，因此，客户端获取到响应包后，需要确定可以处理响应包中的业务数据的业务层。可选地，可以根据数据体中的第二通用字段的参数值，可以确定业务类型的标识，进而确定客户端中用于处理服务器返回的响应包中的业务数据的业务层。
[0149]
依然以上述示例为例，根据status字段的参数值可知，本次服务器对于客户端发送的业务请求的响应是成功的，则进一步地提取数据体中的业务数据，根据business字段的参数值即可确定本次服务器返回的业务数据对应的业务类型，由示例可知，本次服务器返回的响应包中的业务数据的业务类型标识为name，则基于该参数值即可确定客户端中可以处理name业务类型的业务层，并将获取到的详细的业务数据发送至该层级，进行进一步地数据处理。
[0150]
进一步地，从数据体中的数组中提取业务数据，其中，业务类型标识用于指示业务数据所属的业务接口。
[0151]
本公开实施例中，客户端可以从数据体中按第二设定顺序，逐个提取第二通用字段对应的参数值。
[0152]
由上述示例可知，在确定business字段的参数值对应的业务类型后，从actions字段的数组中，可以提取本次业务请求对应的详细业务数据。
[0153]
实现中，客户端可以通过业务接口将业务数据传送至相应的业务层进行数据处理，因此，需要通过业务类型标识确定可以处理当前响应包中的业务数据的业务层对应的业务接口。
[0154]
s404，根据业务类型标识，确定响应包对应的目标业务接口。
[0155]
本公开实施例中，可以基于业务接口的属性信息确定不同的业务接口对应的业务类型标识，并建立业务类型标识和业务接口之间的连接关系。
[0156]
在客户端读取数据体中的业务类型标识后，基于获取到的业务类型标识中的相关关键字，查询预设的连接关系，进而确定当前响应包中的业务数据对应的业务类型所属的业务接口。
[0157]
进一步地，可以将响应包对应的业务接口确定为目标业务接口。
[0158]
在上述示例的基础上，业务类型标识为name对应的接口为接口a，则上述示例中，响应包中业务数据对应的目标业务接口为业务接口a，则数据体中提取出的详细的业务数据需要发送给业务接口a对应的业务层进行数据处理。
[0159]
s405，将业务数据发送给目标业务接口，由目标业务接口的业务层进行处理。
[0160]
本公开实施例中，基于业务类型标识确定目标业务接口后，即可将与目标业务接口对应的业务层确定为处理响应包中的业务数据的业务层。
[0161]
业务层可以根据业务数据携带的各项数组信息，进一步的转化处理，使得客户端可以基于业务数据实现相关的功能。
[0162]
本公开提出的业务请求的响应方法，客户端基于设定的响应逻辑，读取服务器返回的响应包中的消息头和数据体，进而提取业务请求所需的业务数据。基于消息头中字段的参数值，确定服务器基于业务请求的响应的相关属性信息，基于数据体中字段的参数值，确定处理业务数据的业务层，并将提取出的业务数据发送至相应的业务层进行数据处理。本公开中，客户端和服务器可以统一响应解析逻辑，客户端可以基于统一的响应逻辑实现响应包的解包，简化了服务器和客户端之间的数据交互过程，节省了客户端与服务器的开发时间，有效节约了开发资源。
[0163]
作为另一种可能，关于对响应包的解包，可结合图5进一步理解，图5为本公开另一实施例的业务请求的响应方法的流程示意图，该方法适用于客户端，如图5所示，该方法包括：
[0164]
s501，从响应消息进行解析出消息头和数据体。
[0165]
s502，对消息头中按序提取第一通用字段的参数值。
[0166]
步骤s501～s502可参加上述相关详细内容，此处不再赘述。
[0167]
s503，响应于第一通用字段的参数值指示业务请求未响应成功，丢弃响应消息。
[0168]
实现中，客户端可以通过消息头中的第一通用字段的参数值，确定服务器对于业务请求的响应是否成功。服务器与客户端之间设定的响应逻辑中，对于响应异常的情况设定了对应的参数值，基于不同的异常情况，可以为消息头中的第一通用字段赋值不同的参数值。
[0169]
比如，设定响应包中消息头中的部分第一通用字段如下所示：
[0170]
"status":1,
[0171]
"msg":"用户不存在",
[0172]
其中，当第一通用字段中的status字段的参数值为1时，则可以判断服务器响应异常，且通过读取msg字段的参数值可知，服务器响应异常的原因为用户不存在。
[0173]
进一步地，客户端对于响应未成功的响应包，可以进行丢弃处理，并基于响应异常的具体原因在客户端上进行展示。
[0174]
本公开提出的业务请求的响应方法，通过读取消息头中的第一通用字段的参数值，可以判断服务器的响应是否异常，对于响应未成功的响应包进行丢弃处理，有效节约了客户端的存储资源。
[0175]
进一步地，为了更好地理解服务器与客户端之间统一的响应逻辑的建立，可结合如下示例：
[0176]
设定服务器与客户端之间存在两个业务接口，分别为接口a和接口b，在未进行响应逻辑的统一前，接口a和接口b存在各自对应的接口逻辑。
[0177]
则如图6(a)所示，客户端分别基于接口a和接口b的响应逻辑，将业务请求发送至服务器，服务器获取到相应的业务数据后，分别基于接口a和接口b的响应逻辑进行打包，生成对应的响应包，并将其分别通过接口a和接口b返回客户端，客户端分别基于接口a和接口b的响应逻辑进行解包，读取其中的字段以及对应的参数值。
[0178]
为了读取基于上述两种不同的响应格式进行打包生成的响应包，服务器和客户端之间需要设定两套对应的响应逻辑，增加了开发成本，因此，可以将接口a和接口b的响应逻辑进行统一，进而使得服务器可以基于统一的响应格式进行打包，客户端可以基于设定的响应逻辑进行解包，有效节约了开发资源。
[0179]
则可以如图6(b)所示，将接口a和接口b设定为统一的响应逻辑，进而使得服务器和客户端可以基于统一的响应逻辑，在不同的业务接口实现服务器与客户端的信息交互。
[0180]
客户端基于统一的响应逻辑，将业务请求发送至服务器，服务器获取到相应的业务数据后，基于统一的响应逻辑进行打包，生成对应的响应包，并将其分别通过接口a和接口b返回客户端，客户端基于统一的响应逻辑分别对接口a和接口b返回的响应包进行解包，读取其中的字段以及对应的参数值。
[0181]
其中，服务器基于统一的响应逻辑限定的响应格式，分别生成接口a和接口b的响应包中的消息头和数据体，并基于设定顺序排列，进而生成接口a和接口b发送的业务请求对应的响应包。
[0182]
进一步地，为了更好理解上述实施例，可结合图7，图7为本公开另一实施例的业务请求的响应方法的流程示意图，如图7所示：
[0183]
客户端通过业务接口a和业务接口b分别发起业务请求，服务器分别接收业务接口a和业务接口b的业务请求，并分别获取业务接口a和业务接口b的业务请求对应的业务数据，根据服务器和客户端之间统一的响应逻辑限定的响应格式，基于属性信息和业务数据分别打包生成业务接口a和业务接口b的业务请求对应的响应包，并通过业务接口a和业务接口b传输回客户端。
[0184]
客户端基于统一的响应逻辑分别对业务接口a和业务接口b返回的响应包进行解包，读取其中的消息头和数据体。从消息头中的字段的参数值判断服务器的响应状态。若确
定响应成功，则提取数据体中的业务数据，并基于从数据体中获取到的业务类型标识确定进行数据处理的业务层，进而将提取到的详细的业务数据发送至对应的业务层进行数据处理。若确定响应未成功，则将数据体中的业务数据丢弃。
[0185]
本公开中，对服务器和客户端之间的响应逻辑进行了统一，使得服务器可以基于统一的响应格式生成业务请求对应的响应包，以及客户端可以基于统一的响应逻辑实现响应包的解包，简化了服务器和客户端之间的数据交互过程，节省了客户端与服务器的开发时间，有效节约了开发资源。
[0186]
与上述几种实施例提供的业务请求的响应方法相对应，本公开的一个实施例还提供了一种业务请求的响应装置，由于本公开实施例提供的业务请求的响应装置与上述几种实施例提供的业务请求的响应方法相对应，因此上述业务请求的响应方法的实施方式也适用于本公开实施例提供的业务请求的响应装置，在下述实施例中不再详细描述。
[0187]
图8为本公开一实施例的业务请求的响应装置的结构示意图，该装置适用于服务器，如图8所示，业务请求的响应装置100，包括接收模块11、获取模块12、生成模块13，其中：
[0188]
接收模块11，用于接收业务请求，并获取业务请求的属性信息和请求内容；
[0189]
获取模块12，用于根据请求内容，获取业务请求所请求的业务数据；
[0190]
生成模块13，用于根据业务数据和属性信息生成响应包，并将响应包发送至对应的客户端，其中，响应包中包括消息头和数据体，其中，消息头根据属性信息生成，数据体根据属性信息和业务数据生成。
[0191]
图9为本公开一实施例的业务请求的响应装置的结构示意图，该装置适用于服务器，如图9所示，业务请求的响应装置200，包括接收模块21、获取模块22、生成模块23，其中：
[0192]
需要说明的是，接收模块21、获取模块22、生成模块23和接收模块11、获取模块12、生成模块13，具备相同的结构和功能。
[0193]
本公开实施例中，生成模块23，还用于：根据属性信息，对消息头中包括第一设定顺序的第一通用字段进行赋值，生成消息头；根据业务数据和属性信息，对数据体中包括第二设定顺序的第二通用字段和数组进行填充，生成数据体；对消息头和数据体打包生成响应包。
[0194]
本公开实施例中，生成模块23，还用于：获取业务请求的响应状态，根据响应状态对第一通用字段中的目标通用字段进行赋值。
[0195]
本公开实施例中，生成模块23，还用于：从属性信息中提取第一通用字段的配置参数；按照第一设定顺序，基于第一通用字段的配置参数，对第一通用字段进行赋值，生成消息头。
[0196]
本公开实施例中，生成模块23，还用于：从属性信息中提取业务请求的业务类型标识；按照第二设定顺序，基于业务类型标识对第二通用字段进行赋值，并将业务数据写入数组中，以生成数据体。
[0197]
本公开实施例中，接收模块21，还用于：接收客户端通过任一个业务接口发送的业务请求。
[0198]
图10为本公开一实施例的业务请求的响应装置的结构示意图，该装置适用于客户端，如图10所示，业务请求的响应装置300，包括发送模块31、接收模块32、解包模块33，其中：
[0199]
发送模块31，用于向服务器发送业务请求，其中，业务请求包括属性信息和请求内容；
[0200]
接收模块32，用于接收服务器发送的业务请求的响应包，其中，响应消息包括中包括消息头和数据体，其中，消息头根据属性信息生成，数据体根据属性信息和业务数据生成；
[0201]
解包模块33，用于对响应包进行解包，以数据体中获取业务请求所请求的业务数据。
[0202]
图11为本公开一实施例的业务请求的响应装置的结构示意图，该装置适用于客户端，如图11所示，业务请求的响应装置400，包括发送模块41、接收模块42、解包模块43，其中：
[0203]
需要说明的是，发送模块31、接收模块32、解包模块33与发送模块41、接收模块42、解包模块43，具备相同的结构和功能。
[0204]
本公开实施例中，解包模块43，还用于：从响应消息进行解析出消息头和数据体；对消息头中按序提取第一通用字段的参数值；响应于第一通用字段的参数值指示业务请求响应成功，从数据体中提取业务数据；响应于第一通用字段的参数值指示业务请求未响应成功，丢弃响应消息。
[0205]
本公开实施例中，解包模块43，还用于：获取数据体中的第二通用字段的配置参数值，以获取业务请求的业务类型标识；从数据体中的数组中提取业务数据，其中，业务类型标识用于指示业务数据所属的业务接口。
[0206]
本公开实施例中，解包模块43，还用于：根据业务类型标识，确定响应包对应的目标业务接口；将业务数据发送给目标业务接口，由目标业务接口的业务层进行处理。
[0207]
本公开提出的业务请求的响应装置，客户端基于统一的响应逻辑，通过接口a和接口b分别发起业务请求，服务器分别接收接口a和接口b的业务请求，并获取接口a和接口b的业务请求对应的业务数据，基于统一的响应逻辑限定的响应格式，基于属性信息和业务数据分别打包生成接口a和接口b的业务请求对应的响应包，并通过接口a和接口b传输回客户端。客户端基于统一的响应逻辑分别对响应包进行解包，读取其中的消息头和数据体。从消息头中的字段的参数值判断服务器的响应是否成功。若确定响应成功，则提取数据体中的业务数据，并基于业务类型标识确定进行数据处理的业务层，进而将提取到的详细的业务数据发送至对应的业务层进行数据处理。若确定响应为成功，则将数据体中的业务数据丢弃。本公开中，对服务器和客户端之间的响应逻辑进行了统一，进而对业务接口的数据打包的响应格式进行限定，使得服务器可以对不同业务接口对应的不同的业务数据基于相同的格式进行打包，简化了服务器和客户端之间的数据交互过程，节省了客户端与服务器的开发时间，有效节约了开发资源。
[0208]
根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
[0209]
图12示出了可以用来实施本公开的实施例的示例电子设备1200的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计
算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
[0210]
如图12所示，设备1200包括计算单元1201，其可以根据存储在只读存储器(rom)1202中的计算机程序或者从存储单元12012加载到随机访问存储器(ram)1203中的计算机程序，来执行各种适当的动作和处理。在ram 1203中，还可存储设备1200操作所需的各种程序和数据。计算单元1201、rom 1202以及ram 1203通过总线1204彼此相连。输入/输出(i/o)接口1205也连接至总线1204。
[0211]
设备1200中的多个部件连接至i/o接口1205，包括：输入单元1206，例如键盘、鼠标等；输出单元1207，例如各种类型的显示器、扬声器等；存储单元12012，例如磁盘、光盘等；以及通信单元1209，例如网卡、调制解调器、无线通信收发机等。通信单元1209允许设备1200通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
[0212]
计算单元1201可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1201的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1201执行上文所描述的各个方法和处理，例如业务请求的响应方法。例如，在一些实施例中，业务请求的响应方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元12012。在一些实施例中，计算机程序的部分或者全部可以经由rom1202和/或通信单元1209而被载入和/或安装到设备1200上。当计算机程序加载到ram 1203并由计算单元1201执行时，可以执行上文描述的业务请求的响应方法的一个或多个步骤。备选地，在其他实施例中，计算单元1201可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行业务请求的响应方法。
[0213]
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、负载可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
[0214]
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
[0215]
在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计
算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd
‑
rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0216]
为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
[0217]
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
[0218]
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端
‑
服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
[0219]
应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
[0220]
上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。