CN115469841A - 一种应用于iOS终端的请求处理方法和装置 - Google Patents

Abstract

本发明公开了一种应用于iOS终端的请求处理方法和装置，涉及自动程序设计技术领域。该方法的一具体实施方式包括：响应于接收到请求生成指令，确定请求生成指令所属业务类型；从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，其中，每一个业务子类继承预先设置的基础父类，业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程；基于基础父类、一个或多个目标业务子类以及每一个目标业务子类的属性信息，组装出业务请求，并将组装出的业务请求发送给服务端。该实施方式能够有效地降低请求处理工作量和复杂性，有效地提高业务的开发效率。

Description

一种应用于iOS终端的请求处理方法和装置

技术领域

本发明涉及自动程序设计技术领域，尤其涉及一种应用于iOS终端的请求处理方法和装置。

背景技术

依赖于iOS移动操作系统的应用发送给服务端的请求一般包括有请求消息头和请求消息体，其中，针对不同iOS应用的业务请求或者同一iOS应用的不同业务请求的请求消息头或者请求消息体一般包含有不同的请求要素或者请求参数。目前，针对不同业务请求需要基于iOS系统提供的接口进行编写，即针对不同的业务请求需要分别编写业务代码，如果想要为业务请求注入逻辑或者参数，则需要对涉及业务请求的代码进行修改。

现有的这种通过修改部分代码来修改业务请求包括的逻辑或参数的处理方式，可导致业务的开发效率降低，且多人操作涉及业务请求的代码容易造成代码逻辑冲突，导致请求处理工作量和复杂性提升，也将进一步对业务的开发效率造成负面影响。

发明内容

有鉴于此，本发明实施例提供一种应用于iOS终端的请求处理方法和装置，能够有效地降低请求处理工作量和复杂性，以有效地提高业务的开发效率。

为实现上述目的，根据本发明实施例的一个方面，提供了一种应用于iOS终端的请求处理方法，包括：

响应于接收到请求生成指令，确定所述请求生成指令所属业务类型；

从预先设置的多个业务子类中，查找与所述业务类型相匹配的一个或多个目标业务子类以及每一个所述目标业务子类的属性信息，其中，每一个所述业务子类继承预先设置的基础父类，所述业务子类中声明有所述属性信息包括的属性名称及所述属性信息包括的属性值的存储过程和检索过程；

基于所述基础父类、一个或多个所述目标业务子类以及每一个所述目标业务子类的属性信息，组装出业务请求，并将组装出的所述业务请求发送给服务端。

可选地，所述查找与所述业务类型相匹配的一个或多个目标业务子类以及每一个所述目标业务子类的属性信息，包括：

查找与所述业务类型相匹配的对应于请求消息头的一个或多个第一业务子类和/或对应于请求消息体的一个或多个第二业务子类、每一个所述第一业务子类的属性信息和/或每一个所述第二业务子类的属性信息。

可选地，所述组装出业务请求，包括：

根据所述请求生成指令所指示的请求类型，确定业务请求的组装格式，其中，所述请求类型为用于主动发送消息给服务端的发布类或者用于应答服务端的应答类；

从所述基础父类以及一个或多个所述目标业务子类包括的对应于请求消息体的第二业务子类中，获取属于所述请求类型的请求消息体的业务逻辑和一个或多个第一属性名称；

从所述目标业务子类的属性信息包括的第二业务子类的属性信息中，获取一个或多个所述第一属性名称的属性值；

将所述业务逻辑以及键值对形式的一个或多个所述第一属性名称和属性值组装出满足所述组装格式的消息体；

组装所述消息体和为所述请求生成指令确定出的消息头，得到业务请求。

可选地，所述组装出业务请求，进一步包括：

基于所述基础父类包括的涉及请求消息头的部分，确定出所述请求生成指令的消息头；

或者，

基于所述基础父类包括的涉及请求消息头的部分、一个或多个所述目标业务子类包括的对应于请求消息头的第一业务子类中的第二属性名称以及所述目标业务子类的属性信息包括的所述第二属性名称的属性值，确定出所述请求生成指令的消息头。

可选地，在所述获取一个或多个所述第一属性名称的属性值之后，在所述将所述业务逻辑以及键值对形式的一个或多个所述第一属性名称和属性值组装出满足所述组装格式的消息体之前，进一步包括：

根据所述请求生成指令所指示的请求类型，对获取到的每一个所述第一属性名称的属性值进行校验；

所述将所述业务逻辑以及键值对形式的一个或多个所述第一属性名称和属性值组装出满足所述组装格式的消息体，包括：

将通过校验的第一属性名称的属性值以及其对应的第一属性名称以键值对形式组装到消息体。

可选地，上述方法，还包括：

构建出继承所述基础父类的新的业务子类，以通过所述新的业务子类为变更所述业务请求中的属性值或者为所述业务请求增加新的属性信息。

可选地，所述组装出业务请求，还包括：

通过所述基础父类调用iOS系统的NSURLSession类，组装业务请求。

可选地，所述组装出业务请求，包括：

对一个或多个所述目标业务子类和/或所述目标业务子类的属性信息进行拦截，并替换所述目标业务子类的业务逻辑和/或属性信息；

将替换的业务逻辑以及替换的属性信息组装到业务请求。

可选地，所述组装出业务请求，还包括：

识别一个或多个所述目标业务子类是否满足拦截条件；

在满足所述拦截条件的情况下，执行对一个或多个所述目标业务子类和/或所述目标业务子类的属性信息进行拦截的步骤；

在不满足所述拦截条件的情况下，直接执行基于所述基础父类、一个或多个所述目标业务子类以及每一个所述目标业务子类的属性信息，组装出业务请求的步骤。

可选地，在所述组装出业务请求之后，在所述将组装出的所述业务请求发送给服务端之前，进一步包括：

拦截所述业务请求，并对拦截的业务请求进行处理；

所述将组装出的所述业务请求发送给服务端，包括：将处理后的所述业务请求发送给服务端。

可选地，所述对拦截的业务请求进行处理，包括：

对拦截的业务请求包括的业务逻辑和/或属性信息进行修改；

和/或，

调用加解密器对拦截的业务请求进行加密。

可选地，上述方法，还包括：

接收并拦截所述服务端发送的对应于所述业务请求的数据；

对拦截到的所述数据进行处理，并将处理后的数据提供给用户。

第二方面，本发明实施例提供一种应用于iOS终端的请求处理装置，包括：确定模块、请求组装模块以及交互模块，其中，

所述确定模块，响应于接收到请求生成指令，确定所述请求生成指令所属业务类型；

所述请求组装模块，用于从预先设置的多个业务子类中，查找与所述业务类型相匹配的一个或多个目标业务子类以及每一个所述目标业务子类的属性信息，其中，每一个所述业务子类继承预先设置的基础父类，所述业务子类中声明有所述属性信息包括的属性名称及所述属性信息包括的属性值的存储过程和检索过程；基于所述基础父类、一个或多个所述目标业务子类以及每一个所述目标业务子类的属性信息，组装出业务请求；

所述交互模块，用于将组装出的所述业务请求发送给服务端。

根据本发明实施例的另一个方面，还提供了一种电子设备，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行时，所述一个或多个处理器实现上述任一实施例所述的方法。

根据本发明实施例的另一个方面，还提供了一种计算机可读介质，其上存储有计算机程序，所述程序被处理器执行时实现上述任一实施例所述的方法。

根据本发明实施例的另一个方面，还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一实施例所述的方法。

上述发明中的一个实施例具有如下优点或有益效果：通过业务子类继承基础父类的结构设置，可以使不同业务的请求基于各自的业务子类生成，即响应于接收到请求生成指令，确定请求生成指令所属业务类型；从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，然后通过生成该请求所需的基础父类、一个或多个目标业务子类以及每一个目标业务子类中声明有的属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，组装出业务请求，使得用户可以通过构建继承于基础父类的业务子类，由于业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，使得用户在任意位置或时间配置该业务子类的属性信息，即用户需要构建新的业务的请求或者为请求增加参数时，可通过增设业务子类或者为业务子类在任意时间或位置增加属性信息，而无需修改请求生成的代码以及业务逻辑，从而有效地降低请求处理工作量和复杂性，以有效地提高业务的开发效率。

上述的非惯用的可选方式所具有的进一步效果将在下文中结合具体实施方式加以说明。

附图说明

附图用于更好地理解本发明，不构成对本发明的不当限定。其中：

图1是本发明实施例可以应用于其中的一种示例性系统架构图；

图2是根据本发明实施例的应用于iOS终端的请求处理方法的主要流程的示意图；

图3是根据本发明实施例的基础父类与业务子类之间关系的结构示意图；

图4是根据本发明实施例的组装出业务请求的主要流程的示意图；

图5是根据本发明实施例的组装出业务请求中的消息头的主要流程示意图；

图6是根据本发明实施例的基础父类、与消息体相关的业务子类以及与消息头相关的子类之间关系的结构示意图；

图7是根据本发明一个实施例的一种组装出业务请求的主要流程的示意图；

图8是根据本发明另一个实施例的另一种组装出业务请求的主要流程的示意图；

图9是根据本发明实施例的一种对组装后的请求进行拦截处理的主要流程的示意图；

图10是根据本发明实施例的另一种对组装后的请求进行拦截处理的主要流程的示意图；

图11是根据本发明另一实施例的应用于iOS终端的请求处理方法的主要流程的示意图；

图12是根据本发明实施例的应用于iOS终端的请求处理装置的主要模块的示意图；

图13是适于用来实现本发明实施例的终端设备的计算机系统的结构示意图。

具体实施方式

以下结合附图对本发明的示范性实施例做出说明，其中包括本发明实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本发明的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本发明实施例的应用于iOS终端的请求处理方法一般是由iOS终端安装的客户端的实现的，相应地，应用于iOS终端的请求处理装置一般为iOS终端安装的客户端的一部分或者一个功能模块/功能单元。

图1示出了可以应用本发明实施例的应用于iOS终端的请求处理方法或应用于iOS终端的请求处理装置的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103，网络104以及服务器105。其中，终端设备101、102、103安装有实现本发明实施例提供的应用于iOS终端的请求处理方法的客户端。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101、102、103通过网络104与服务器105交互，以发送针对业务的请求或者针对服务器105的应答请求给服务器105等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。

终端设备101、102、103在接收到请求生成指令的情况下，基于预设的基础父类、与该请求生成指令相匹配的一个或多个目标业务子类以及每一个目标业务子类声明的属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，组装出业务请求，并将该业务请求发送给服务器105。该业务请求可以为终端设备101、102、103主动发送给服务器105的用于请求服务器105执行业务的请求，也可以为终端设备101、102、103针对服务器105发送的信息的应答反馈。

终端设备101、102、103可以是具有显示屏并且支持网页浏览的各种安装有iOS系统的电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器105可以是提供各种服务的服务器，例如对终端设备101、102、103的业务提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对基于终端设备101、102、103的请求，处理业务，并将处理结果反馈给终端设备。

需要说明的是，本发明实施例所提供的应用于iOS终端的请求处理方法一般由终端设备101、102、103执行，相应地，应用于iOS终端的请求处理装置一般设置于终端设备101、102、103中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

图1示出的在安装有iOS系统的终端设备实现的请求处理方法，可包括图2所示出的本发明实施例的一种应用于iOS终端的请求处理方法的主要流程。

图2是根据本发明实施例的一种应用于iOS终端的请求处理方法的主要流程的示意图。如图2所示，该应用于iOS终端的请求处理方法可包括如下步骤：

步骤S201：响应于接收到请求生成指令，确定请求生成指令所属业务类型；

其中，接收到请求生成指令可以为由于用户触发页面的按键/按钮或者终端设备为了应答服务端发送的信息，终端设备生成的指令，以使终端设备基于该指令生成业务的请求。

该业务类型可以是根据业务所对应的业务子类划分的，也可是根据具体的业务功能划分的，比如，该业务类型可以为账单查询业务类型、入账业务类型、还款业务类型、付款业务类型、下单业务类型、人工服务业务类型等。该业务类型可根据用户需要或者业务子类的设置进行划分。

步骤S202：从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，其中，每一个业务子类继承预先设置的基础父类，业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程；

其中，业务子类是通过objc-c语言实现的、以property(该property是iOS提供的一种类的属性的结构，其规定了属性的种类，如NSString代表字符串，NSArray代表数组等)的形式声明属性，以实现特定业务功能比如账单查询、入账、还款、付款等的方法。

基础父类是为各种业务子类生成业务的请求提供所需的基础的信息的方法。

其中，基础父类与业务子类之间关系可如图3所示。图3示例性地给出了多个业务子类，分别为业务子类1、2、3、……、N，这些业务子类1、2、3、……、N继承基础父类，各个业务子类1、2、3、……、N之间相对独立。即用户可以通过增加新的业务子类，使终端设备能够生成新的业务请求，以满足请求扩展的需求。

通过在业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，可以使用户在任意时间点设置业务子类的属性值，并可将配置的属性值存储在任意位置，使业务的配置具有灵活性。

另外，通过配置业务子类实现新的业务请求，使用户只需要关注自身配置的业务子类即可，而无需关注全局的业务代码逻辑，以有效地提高各种类型业务请求的开发。

步骤S203：基于基础父类、一个或多个目标业务子类以及每一个目标业务子类的属性信息，组装出业务请求，并将组装出的业务请求发送给服务端。

该步骤主要是根据基础父类以及一个或多个目标业务子类给出的处理逻辑和基础父类以及一个或多个目标业务子类声明的属性信息，将属性信息的属性名称和属性值以及请求所需包括的业务逻辑封装成包含消息头和消息体的请求。

在图2所示的实施例中，通过业务子类继承基础父类的结构设置，可以使不同业务的请求基于各自的业务子类生成，即响应于接收到请求生成指令，确定请求生成指令所属业务类型；从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，然后通过生成该请求所需的基础父类、一个或多个目标业务子类以及每一个目标业务子类中声明有的属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，组装出业务请求，使得用户可以通过构建继承于基础父类的业务子类，由于业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，使得用户在任意位置或时间配置该业务子类的属性信息，即用户需要构建新的业务的请求或者为请求增加参数时，可通过增设业务子类或者为业务子类在任意时间或位置增加属性信息，而无需修改请求生成的代码以及业务逻辑，从而有效地降低请求处理工作量和复杂性，以有效地提高业务的开发效率。

另外，通过构建不同的业务子类和业务子类的属性信息的声明，方便不同工作人员对业务请求的修改和维护，使不同工作人员对业务请求的修改和维护之间不造成冲突，同时请求生成所需逻辑与业务代码解耦，避免对业务代码的修改。

在本发明实施例中，上述查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息地具体实施方式可包括：查找与业务类型相匹配的对应于请求消息头的一个或多个第一业务子类和/或对应于请求消息体的一个或多个第二业务子类、每一个第一业务子类的属性信息和/或每一个第二业务子类的属性信息。其中，第一业务子类和第二业务子类可以属于同一业务子类，也可以属于不同的业务子类。通过分别查找对应于消息头的一个或多个第一业务子类以及对应于请求消息体的一个或多个第二业务子类，可以将消息头和消息体分别配置，以实现消息体和消息头解除耦合，更方便对消息头和消息体隔离配置，进一步提高业务生成请求的可配置化。

在本发明实施例中，如图4所示，上述组装出业务请求的具体实施方式可包括如下步骤：

步骤S401：根据请求生成指令所指示的请求类型，确定业务请求的组装格式，其中，请求类型为用于主动发送消息给服务端的发布类或者用于应答服务端的应答类；

由于不同请求类型的请求，格式存在一定的差异，通过确定业务请求的组装格式可以使组装出的请求能够满足服务端需求，以使服务端能够准确的获知请求是发布类请求还是应答类请求，并使服务端能够从请求中准确读取到所需参数、请求包括的业务逻辑等。另外，通过按照组装格式组装请求，可以使组装出的请求能够满足现有的终端与服务端交互的请求协定，减少对终端与服务端之间交互的侵入性修改。

步骤S402：从基础父类以及一个或多个目标业务子类包括的对应于请求消息体的第二业务子类中，获取属于请求类型的请求消息体的业务逻辑和一个或多个第一属性名称；

步骤S403：从目标业务子类的属性信息包括的第二业务子类的属性信息中，获取一个或多个第一属性名称的属性值；

步骤S404：将业务逻辑以及键值对形式的一个或多个第一属性名称和属性值组装出满足组装格式的消息体；

其中，键值对(key-value)中，第一属性名称为key，其对应的属性值为value。通过前面提及的业务子类中声明的属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程以及键值对形式的一个或多个第一属性名称和属性值，可以在请求发起前多次给该业务子类的不同属性进行赋值，也可以给相同属性进行赋值，此时新值会替换旧值。通过这种业务子类中声明的属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程以及键值对形式的一个或多个第一属性名称和属性值，使编写代码人员能更清晰的查看每个消息体中所包含的字段，且更易于修改。

步骤S405：组装消息体和为请求生成指令确定出的消息头，得到业务请求。

其中，组装出业务请求还可包括：通过基础父类调用iOS系统的NSURLSession类，组装业务请求。该NSURLSession类为iOS系统本身存在的常用网络内部类。本申请的基础父类通过调用iOS系统的NSURLSession类实现生成请求，不仅减少了用户构建类的复杂性，同时能够减少对iOS系统生成请求的侵入性修改，即依赖iOS系统本身具有的NSURLSession类，实现不同业务请求之间以及业务请求与业务逻辑代码之间的解耦合，同时能够更好地贴合iOS系统的需求。

针对组装出业务请求中的消息头可以有两种实现。

第一种组装出业务请求中的消息头的实现：基于基础父类包括的涉及请求消息头的部分，确定出请求生成指令的消息头。

如图5所示的结构图中包括有基础父类以及用于生成消息头的子类a和子类b，其中，子类a和子类b继承该基础父类。该基础父类中包含有对应于消息头的部分，那么，针对不需要对消息头进行变更的请求来说，可以仅通过基础父类实现对消息头处理，得到请求的消息头。

第二种组装出业务请求中的消息头的实现：基于基础父类包括的涉及请求消息头的部分、一个或多个目标业务子类包括的对应于请求消息头的第一业务子类中的第二属性名称以及目标业务子类的属性信息包括的第二属性名称的属性值，确定出请求生成指令的消息头。

比如，图5所示出的子类a和子类b均为对应于请求消息头的第一业务子类，通过基础父类以及子类a进行子类a的消息头处理，得到对应于子类a的业务请求的消息头，通过基础父类即子类b进行子类b的消息头处理，得到对应于子类b的业务请求的消息头。

通过上述可以满足不同消息头的需求。

值得说明的是，上述消息头的第一业务子类与消息体的第二业务子类可以同属于一个业务子类，也可以属于不同的业务子类。

综上可知，消息头可以是由基础父类得到，也可以由继承基础父类的子类得到，该继承基础父类的子类可以包含实现消息体的逻辑方法，也可以不包含。下面以图6示出的通过不同方式得到的业务A的请求、业务B的请求以及业务C的请求。

比如，针对业务A请求来说，其消息头是由基础父类进行消息头处理得到的，消息体是由继承基础父类的业务子类A得到的，通过组装该基础父类进行消息头处理得到的消息头以及务子类A得到的消息体得到业务A请求。针对业务B请求，其消息头和消息体是由继承基础父类的业务子类B通过消息头处理和消息体处理得到的。针对业务C请求，其消息头是由继承消息头子类C'进行消息头处理得到的，消息体是由继承基础父类的业务子类C进行消息体处理得到的。通过该种实现，可以满足不同业务请求的生成需求。

在本发明实施例中，在获取一个或多个第一属性名称的属性值之后，在将业务逻辑以及键值对形式的一个或多个第一属性名称和属性值组装出满足组装格式的消息体之前还可进一步包括：根据请求生成指令所指示的请求类型，对获取到的每一个第一属性名称的属性值进行校验；相应地，将业务逻辑以及键值对形式的一个或多个第一属性名称和属性值组装出满足所述组装格式的消息体的具体实施方式可包括：将通过校验的第一属性名称的属性值以及其对应的第一属性名称以键值对形式组装到消息体。其中，比如，校验可以为判断字符串长度是否大于1，数组里是否有值等，通过校验可以排除不符合规则或者格式的属性值，将剩于的满足规则或者格式的属性值组成消息体，以保证消息体内的参数均能够被服务端识别，避免不满足格式或者规则的属性值仍然被组装到请求中造成的请求失败的问题。

在本发明实施例中，如图7所示，上述组装出业务请求的具体实施方式可包括如下步骤：

步骤S701：对一个或多个目标业务子类和/或目标业务子类的属性信息进行拦截，并替换目标业务子类的业务逻辑和/或属性信息；

步骤S702：将替换的业务逻辑以及替换的属性信息组装到业务请求。

即通过在组装业务请求之前即对目标业务子类和/或目标业务子类的属性信息进行拦截，以替换原有的目标业务子类和/或目标业务子类的属性信息实现对业务请求的修改，避免对目标业务子类的修改，进一步提高业务请求更新的灵活性。同时，通过拦截方式，实现在业务代码外进行拦截注入修改，与业务开发不冲突，降低对业务开发的依赖。

在本发明实施例中，如图8所示，上述组装出业务请求的具体实施方式还可进一步包括如下步骤：

步骤S801：识别一个或多个目标业务子类是否满足拦截条件，在满足拦截条件的情况下，执行步骤S802；在不满足拦截条件的情况下，执行步骤S803；

该拦截条件可以根据用户需求进行设置，比如对于某一类型的业务子类进行拦截或者对于包含某一属性的业务子类进行拦截等，以通过该拦截条件实现选择性地拦截目标业务子类和/或目标业务子类的属性信息。

步骤S802：执行对一个或多个目标业务子类和/或目标业务子类的属性信息进行拦截的步骤；

步骤S803：直接执行基于基础父类、一个或多个目标业务子类以及每一个目标业务子类的属性信息，组装出业务请求的步骤。

通过该图8提供的方案实现按照用户设置的拦截条件，根据需求拦截目标业务子类，实现通过拦截目标业务子类修改得到的请求，以避免对原有业务子类的侵入性修改，保证了请求生成逻辑的非侵入式的可扩展性。

在本发明实施例中，在组装出业务请求之后，还可进一步包括：拦截业务请求，并对拦截的业务请求进行处理；将处理后的业务请求发送给服务端。该步骤可以通过设置拦截器来拦截业务请求实现。拦截业务请求，在业务代码外进行拦截注入修改，与业务开发不冲突，方便多人操作和维护。

具体地，上述对拦截的业务请求进行处理的具体实施方式可包括：对拦截的业务请求包括的业务逻辑和/或属性信息进行修改。如图9所示，通过业务层基于业务数据以及上述实施例组装出的业务请求发起请求，拦截器在拦截请求后，对请求中的参数进行修改后者增加，将修改了参数或者增加了参数的请求重新发送给服务端，在接收到服务端返回的数据后，拦截器还可对服务端返回的数据进行拦截，以修改数据或者格式化数据，并通过业务层处理修改后的或者格式化后的数据，通过该过程降低业务层与服务端之间数据的耦合，即使服务端可以返回任意格式的数据，通过拦截器可以将服务端的数据修改为能够被业务层读取的格式。

另外，上述对拦截的业务请求进行处理的具体实施方式可包括：调用加解密器对拦截的业务请求进行加密。具体地，如图10所示，拦截器在拦截到组装的请求后，将该请求发送给加解密器，通过加解密器对请求进行加密，然后将加密后的请求发送给服务端，拦截器再进一步接收到服务端反馈的数据的情况下，将该数据发送给加解密器进行解密，并将解密后的数据发送给业务层。通过设置加解密器，使加密请求和解密数据的过程与生成请求的过程解耦合，对业务代码不造成破坏影响。另外，还可选择替换不同的加解密逻辑，降低请求处理的复杂度。

值得说明的是，加解密器中所选用的的加解密方法是客户端与服务端之间协商确定的，在此并不做限定。

如图9和图10所示，上述方法还可进一步包括：接收并拦截服务端发送的对应于业务请求的数据；对拦截到的数据进行处理，并将处理后的数据提供给用户。

另外，上述方法还可进一步包括：构建出继承基础父类的新的业务子类，以通过新的业务子类为变更业务请求中的属性值或者为业务请求增加新的属性信息。以实现生成不同业务类型的请求的扩展。

在本发明另一实施例中，如图11所示，提供的另一种应用于iOS终端的请求处理方法可包括如下步骤：

步骤S1100：构建出继承基础父类的多个业务子类；

步骤S1101：响应于接收到请求生成指令，确定请求生成指令所属业务类型；

步骤S1102：从预先设置的多个业务子类中，查找与业务类型相匹配的对应于请求消息头的一个或多个第一业务子类和/或对应于请求消息体的一个或多个第二业务子类、每一个第一业务子类的属性信息和/或每一个第二业务子类的属性信息；

其中，每一个业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程；

步骤S1103：根据请求生成指令所指示的请求类型，确定业务请求的组装格式；

其中，请求类型为用于主动发送消息给服务端的发布类或者用于应答服务端的应答类；

步骤S1104：基于基础父类包括的涉及请求消息头的部分、一个或多个第一业务子类中的第二属性名称以及第一业务子类的属性信息包括的第二属性名称的属性值，确定出请求生成指令的消息头；

该步骤S1104还可以基于基础父类包括的涉及请求消息头的部分，确定出请求生成指令的消息头。

步骤S1105：识别一个或多个第二业务子类是否满足拦截条件；在满足拦截条件的情况下，执行步骤S1106；在不满足拦截条件的情况下，执行步骤S1107；

步骤S1106：对一个或多个第二业务子类和/或第二业务子类的属性信息进行拦截，并替换第二业务子类的业务逻辑和/或属性信息，执行步骤S1109；

步骤S1107：从基础父类以及一个或多个对应于请求消息体的第二业务子类中，获取属于请求类型的请求消息体的业务逻辑和一个或多个第一属性名称；

步骤S1108：从第二业务子类的属性信息中，获取一个或多个第一属性名称的属性值；

步骤S1109：根据请求生成指令所指示的请求类型，对获取到的每一个第一属性名称的属性值进行校验；

步骤S1110：将通过校验的第一属性名称的属性值以及其对应的第一属性名称以键值对形式组装出满足组装格式的消息体；

步骤S1111：组装消息体和为请求生成指令确定出的消息头，得到业务请求；

步骤S1112：通过拦截器拦截业务请求，并对拦截的业务请求对拦截的业务请求包括的业务逻辑和/或属性信息进行修改；

步骤S1113：调用加解密器对拦截的业务请求进行加密；

步骤S1114：将加密后的业务请求发送给服务端；

步骤S1115：接收并拦截服务端发送的对应于业务请求的数据；

步骤S1116：对拦截到的数据进行解密，并将解密后的数据提供给用户。

值得说明的是，上述图11给出的实施例是实现生成请求并接收请求所对应的数据的一种实施例，其他包含该实施例的多个步骤的组合，也均在本申请的保护范围内。比如，在执行完步骤S1104之后，直接执行步骤S1107；在执行完成步骤S1111之后直接发送组装的请求给服务端等均在本申请的保护范围内。

如图12所示，本发明实施例提供一种应用于iOS终端的请求处理装置1200，该应用于iOS终端的请求处理装置1200可包括：确定模块1201、请求组装模块1202以及交互模块1203，其中，

确定模块1201，响应于接收到请求生成指令，确定请求生成指令所属业务类型；

请求组装模块1202，用于从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，其中，每一个业务子类继承预先设置的基础父类，业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程；基于基础父类、一个或多个目标业务子类以及每一个目标业务子类的属性信息，组装出业务请求；

交互模块1203，用于将组装出的业务请求发送给服务端。

在本发明实施例中，请求组装模块1202，用于查找与业务类型相匹配的对应于请求消息头的一个或多个第一业务子类和/或对应于请求消息体的一个或多个第二业务子类、每一个第一业务子类的属性信息和/或每一个第二业务子类的属性信息。

在本发明实施例中，请求组装模块1202，进一步用于根据请求生成指令所指示的请求类型，确定业务请求的组装格式，其中，请求类型为用于主动发送消息给服务端的发布类或者用于应答服务端的应答类；从基础父类以及一个或多个目标业务子类包括的对应于请求消息体的第二业务子类中，获取属于请求类型的请求消息体的业务逻辑和一个或多个第一属性名称；从目标业务子类的属性信息包括的第二业务子类的属性信息中，获取一个或多个第一属性名称的属性值；将业务逻辑以及键值对形式的一个或多个第一属性名称和属性值组装出满足组装格式的消息体；组装消息体和为请求生成指令确定出的消息头，得到业务请求。

在本发明实施例中，请求组装模块1202，进一步用于基于基础父类包括的涉及请求消息头的部分，确定出请求生成指令的消息头。

在本发明实施例中，请求组装模块1202，进一步用于基于基础父类包括的涉及请求消息头的部分、一个或多个目标业务子类包括的对应于请求消息头的第一业务子类中的第二属性名称以及目标业务子类的属性信息包括的第二属性名称的属性值，确定出请求生成指令的消息头。

在本发明实施例中，请求组装模块1202，进一步用于根据请求生成指令所指示的请求类型，对获取到的每一个第一属性名称的属性值进行校验；将通过校验的第一属性名称的属性值以及其对应的第一属性名称以键值对形式组装到消息体。

在本发明实施例中，请求组装模块1202，进一步用于接收用户构建出的继承基础父类的新的业务子类，以通过新的业务子类为变更业务请求中的属性值或者为业务请求增加新的属性信息。

在本发明实施例中，请求组装模块1202，进一步用于通过基础父类调用iOS系统的NSURLSession类，组装业务请求。

在本发明实施例中，如图12所示，上述请求处理装置1200可进一步包括：第一拦截器1204，其中，

第一拦截器1204，用于对一个或多个目标业务子类和/或目标业务子类的属性信息进行拦截，并替换目标业务子类的业务逻辑和/或属性信息；

请求组装模块1202，进一步用于将第一拦截器1204替换的业务逻辑以及替换的属性信息组装到业务请求。

在本发明实施例中，第一拦截器1204，用于识别一个或多个目标业务子类是否满足拦截条件；在满足拦截条件的情况下，执行对一个或多个目标业务子类和/或目标业务子类的属性信息进行拦截的步骤；在不满足拦截条件的情况下，触发请求组装模块1202；

请求组装模块1202，进一步用于在接收到第一拦截器1204的触发的情况下，直接执行基于基础父类、一个或多个目标业务子类以及每一个目标业务子类的属性信息，组装出业务请求的步骤。

在本发明实施例中，上述请求处理装置1200可进一步包括：第二拦截器1205，其中，

第二拦截器1205，用于拦截业务请求，并对拦截的业务请求进行处理；

交互模块1203，用于将处理后的业务请求发送给服务端。

在本发明实施例中，第二拦截器1205，进一步用于对拦截的业务请求包括的业务逻辑和/或属性信息进行修改。

在本发明实施例中，如图12所示，上述请求处理装置1200可进一步包括：加解密器1206，其中，

第二拦截器1205，进一步用于调用加解密器1206对拦截的业务请求进行加密。

下面参考图13，其示出了适于用来实现本发明实施例的终端设备的计算机系统1300的结构示意图。图13示出的终端设备仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图13所示，计算机系统1300包括中央处理单元(CPU)1301，其可以根据存储在只读存储器(ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(RAM)1303中的程序而执行各种适当的动作和处理。在RAM 1303中，还存储有系统1300操作所需的各种程序和数据。CPU 1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

以下部件连接至I/O接口1305：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。

特别地，根据本发明公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本发明公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。在该计算机程序被中央处理单元(CPU)1301执行时，执行本发明的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本发明实施例中所涉及到的模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的模块也可以设置在处理器中，例如，可以描述为：一种处理器包括确定模块、请求组装模块以及交互模块。其中，这些模块的名称在某种情况下并不构成对该模块本身的限定，例如，确定模块还可以被描述为“确定请求生成指令所属业务类型的模块”。

作为另一方面，本发明还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该设备执行时，使得该设备包括：响应于接收到请求生成指令，确定请求生成指令所属业务类型；从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，其中，每一个业务子类继承预先设置的基础父类，业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程；基于基础父类、一个或多个目标业务子类以及每一个目标业务子类的属性信息，组装出业务请求，并将组装出的业务请求发送给服务端。

作为另一方面，本发明实施例还提供了一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现上述任一实施例所述的方法。

根据本发明实施例的技术方案，通过业务子类继承基础父类的结构设置，可以使不同业务的请求基于各自的业务子类生成，即响应于接收到请求生成指令，确定请求生成指令所属业务类型；从预先设置的多个业务子类中，查找与业务类型相匹配的一个或多个目标业务子类以及每一个目标业务子类的属性信息，然后通过生成该请求所需的基础父类、一个或多个目标业务子类以及每一个目标业务子类中声明有的属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，组装出业务请求，使得用户可以通过构建继承于基础父类的业务子类，由于业务子类中声明有属性信息包括的属性名称及属性信息包括的属性值的存储过程和检索过程，使得用户在任意位置或时间配置该业务子类的属性信息，即用户需要构建新的业务的请求或者为请求增加参数时，可通过增设业务子类或者为业务子类在任意时间或位置增加属性信息，而无需修改请求生成的代码以及业务逻辑，从而有效地降低请求处理工作量和复杂性，以有效地提高业务的开发效率。

上述具体实施方式，并不构成对本发明保护范围的限制。本领域技术人员应该明白的是，取决于设计要求和其他因素，可以发生各种各样的修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明保护范围之内。

Claims (16)

1.一种应用于iOS终端的请求处理方法，其特征在于，包括：

响应于接收到请求生成指令，确定所述请求生成指令所属业务类型；

从预先设置的多个业务子类中，查找与所述业务类型相匹配的一个或多个目标业务子类以及每一个所述目标业务子类的属性信息，其中，每一个所述业务子类继承预先设置的基础父类，所述业务子类中声明有所述属性信息包括的属性名称及所述属性信息包括的属性值的存储过程和检索过程；

基于所述基础父类、一个或多个所述目标业务子类以及每一个所述目标业务子类的属性信息，组装出业务请求，并将组装出的所述业务请求发送给服务端。

2.根据权利要求1所述的方法，其特征在于，所述查找与所述业务类型相匹配的一个或多个目标业务子类以及每一个所述目标业务子类的属性信息，包括：

查找与所述业务类型相匹配的对应于请求消息头的一个或多个第一业务子类和/或对应于请求消息体的一个或多个第二业务子类、每一个所述第一业务子类的属性信息和/或每一个所述第二业务子类的属性信息。

3.根据权利要求1或2所述的方法，其特征在于，所述组装出业务请求，包括：

根据所述请求生成指令所指示的请求类型，确定业务请求的组装格式，其中，所述请求类型为用于主动发送消息给服务端的发布类或者用于应答服务端的应答类；

从所述基础父类以及一个或多个所述目标业务子类包括的对应于请求消息体的第二业务子类中，获取属于所述请求类型的请求消息体的业务逻辑和一个或多个第一属性名称；

从所述目标业务子类的属性信息包括的第二业务子类的属性信息中，获取一个或多个所述第一属性名称的属性值；

将所述业务逻辑以及键值对形式的一个或多个所述第一属性名称和属性值组装出满足所述组装格式的消息体；

组装所述消息体和为所述请求生成指令确定出的消息头，得到业务请求。

4.根据权利要求3所述的方法，其特征在于，所述组装出业务请求，进一步包括：

基于所述基础父类包括的涉及请求消息头的部分，确定出所述请求生成指令的消息头；

或者，

基于所述基础父类包括的涉及请求消息头的部分、一个或多个所述目标业务子类包括的对应于请求消息头的第一业务子类中的第二属性名称以及所述目标业务子类的属性信息包括的所述第二属性名称的属性值，确定出所述请求生成指令的消息头。

5.根据权利要求3所述的方法，其特征在于，在所述获取一个或多个所述第一属性名称的属性值之后，在所述将所述业务逻辑以及键值对形式的一个或多个所述第一属性名称和属性值组装出满足所述组装格式的消息体之前，进一步包括：

根据所述请求生成指令所指示的请求类型，对获取到的每一个所述第一属性名称的属性值进行校验；

所述将所述业务逻辑以及键值对形式的一个或多个所述第一属性名称和属性值组装出满足所述组装格式的消息体，包括：

将通过校验的第一属性名称的属性值以及其对应的第一属性名称以键值对形式组装到消息体。

6.根据权利要求1所述的方法，其特征在于，还包括：

构建出继承所述基础父类的新的业务子类，以通过所述新的业务子类为变更所述业务请求中的属性值或者为所述业务请求增加新的属性信息。

7.根据权利要求1所述的方法，其特征在于，所述组装出业务请求，还包括：

通过所述基础父类调用iOS系统的NSURLSession类，组装业务请求。

8.根据权利要求1所述的方法，其特征在于，所述组装出业务请求，包括：

对一个或多个所述目标业务子类和/或所述目标业务子类的属性信息进行拦截，并替换所述目标业务子类的业务逻辑和/或属性信息；

将替换的业务逻辑以及替换的属性信息组装到业务请求。

9.根据权利要求8所述的方法，其特征在于，所述组装出业务请求，还包括：

识别一个或多个所述目标业务子类是否满足拦截条件；

在满足所述拦截条件的情况下，执行对一个或多个所述目标业务子类和/或所述目标业务子类的属性信息进行拦截的步骤；

在不满足所述拦截条件的情况下，直接执行基于所述基础父类、一个或多个所述目标业务子类以及每一个所述目标业务子类的属性信息，组装出业务请求的步骤。

10.根据权利要求1所述的方法，其特征在于，在所述组装出业务请求之后，进一步包括：

拦截所述业务请求，并对拦截的业务请求进行处理；

所述将组装出的所述业务请求发送给服务端，包括：将处理后的所述业务请求发送给服务端。

11.根据权利要求10所述的方法，其特征在于，所述对拦截的业务请求进行处理，包括：

对拦截的业务请求包括的业务逻辑和/或属性信息进行修改；

和/或，

调用加解密器对拦截的业务请求进行加密。

12.根据权利要求1、10以及11中任一项所述的方法，其特征在于，还包括：

接收并拦截所述服务端发送的对应于所述业务请求的数据；

对拦截到的所述数据进行处理，并将处理后的数据提供给用户。

13.一种应用于iOS终端的请求处理装置，其特征在于，包括：确定模块、请求组装模块以及交互模块，其中，

所述确定模块，响应于接收到请求生成指令，确定所述请求生成指令所属业务类型；

所述请求组装模块，用于从预先设置的多个业务子类中，查找与所述业务类型相匹配的一个或多个目标业务子类以及每一个所述目标业务子类的属性信息，其中，每一个所述业务子类继承预先设置的基础父类，所述业务子类中声明有所述属性信息包括的属性名称及所述属性信息包括的属性值的存储过程和检索过程；基于所述基础父类、一个或多个所述目标业务子类以及每一个所述目标业务子类的属性信息，组装出业务请求；

所述交互模块，用于将组装出的所述业务请求发送给服务端。

14.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求1-12中任一所述的方法。

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

16.一种计算机程序产品，包括计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-12中任一项所述的方法。

Images