CN105306602A - 超文本传输协议请求的处理方法、处理装置和服务器 - Google Patents

Abstract

本发明提出了一种超文本传输协议请求的处理方法、超文本传输协议请求的处理装置和服务器，其中，所述超文本传输协议请求的处理方法包括：对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。通过本发明的技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

Description

超文本传输协议请求的处理方法、处理装置和服务器

技术领域

本发明涉及服务器技术领域，具体而言，涉及一种超文本传输协议请求的处理方法、一种超文本传输协议请求的处理装置和一种服务器。

背景技术

目前，在Web(互联网)程序开发中，HTTP(HypertextTransferProtocol，超文本传输协议)请求意味着业务的开始，即由客户端向服务器发送HTTP数据包，其中，所述HTTP数据包中包括：消息首行、对资源信息的请求方法、资源信息的URI(UniformResourceIdentifier，统一资源标识符)及使用协议。HTTP请求中用统一资源标识符指明了业务的资源信息及业务的参数。在将HTTP请求发送至服务器后，HTTP请求最终都会由业务处理逻辑的动作(即ACTION)来进行处理，其中，ACTION是用WEB程序开发语言编写，驻留在服务器中，对HTTP请求进行响应，并实际处理业务逻辑，完成后将结果返回。

现有技术中服务器对HTTP请求进行处理的方法并不统一，有的是将对HTTP请求进行处理的方法直接写在程序源代码中，如果业务的资源信息的URI发生变化，或者要增加新的业务，就需要修改程序源代码，这样就导致了用户(如程序员)的工作量非常大。而有的是在系统设计之初强制指定URI的模式，每一种模式由一个特定的ACTION进行处理，这种约束不明了、难管理，对那些不符合任何约定模式的URI无能为力。

因此，如何使得服务器对HTTP请求的处理更加灵活、简单成为目前亟待解决的问题。

发明内容

本发明正是基于上述问题，提出了一种新的技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

有鉴于此，本发明的第一方面提出了一种超文本传输协议请求的处理方法，用于服务器，包括：对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。

在该技术方案中，通过对接收到的超文本传输协议请求(即HTTP请求)进行解析，并根据解析结果在超文本传输协议请求中获取统一资源标识符和客户端与服务器的交互类型，其中，客户端与服务器的交互类型包括：读取资源信息(GET)、向服务器提交资源信息(POST)、更新服务器上的资源信息(PUT)、删除服务器上的资源信息(DELETE)、读取资源信息的头部信息(HEAD)、使用WebSocket协议获取资源信息(WS)，从而根据交互类型和统一资源标识符在已定义的多个路由中选择目标路由，其中，已定义的多个路由可以存储在路由文件中，用户可以随时对该路由文件中的多个路由进行修改或增加，进一步地，根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理，因此，通过上述技术方案，避免了相关技术中由于超文本传输协议请求的处理方法直接写在程序源代码中，从而避免了在超文本传输协议请求中的统一资源标识符变化时需要修改程序源代码的繁琐操作，进而使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述技术方案中，优选地，所述根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由的步骤，具体包括：在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由，并根据所述至少一个路由确定所述目标路由。

在该技术方案中，通过将多个路由与交互类型和统一资源标识符进行匹配，并根据与交互类型和统一资源标识符匹配的至少一个路由确定目标路由，由于用户可随时对多个路由进行修改或者增加，也就使得在统一资源标识符发生改变时，直接修改多个路由中的统一资源标识符，然后再根据交互类型和变化后的统一资源标识符与多个路由进行匹配来确定目标路由，如此，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述任一技术方案中，优选地，所述在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由的步骤，具体包括：在所述多个路由中选择与所述交互类型匹配的路由；判断在与所述交互类型匹配的路由中是否存在与所述统一资源标识符匹配的路由；在判断结果为是时，将与所述统一资源标识符匹配的路由作为所述至少一个路由；否则，构造错误信息，并将所述错误信息发送至所述客户端。

在该技术方案中，若判定在与交互类型匹配的路由中存在与统一资源标识符匹配的路由，则将与统一资源标识符匹配的路由作为至少一个路由，否则，即没有与统一资源标识符匹配的路由，则构造错误信息，并将错误信息发送至客户端，因此，通过上述技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述任一技术方案中，优选地，若所述至少一个路由的数量为多个，则根据所述至少一个路由确定所述目标路由的步骤，具体包括：根据所述多个路由的路由规则获取所述至少一个路由的优先级；将所述至少一个路由中优先级最高的路由作为所述目标路由。

在该技术方案中，根据多个路由的路由规则获取至少一个路由的优先级，例如，根据路由可信度(即管理距离)来确定至少一个路由的优先级(路由的管理距离越小，路由的优先级越高)，然后将至少一个路由中优先级最高的路由作为目标路由，因此，通过上述技术方案，通过选取优先级最高的路由作为目标路由，有效地提升了根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理的可靠性。

在上述任一技术方案中，优选地，所述对接收到的超文本传输协议请求进行解析的步骤之前，包括：接收来自所述客户端的所述超文本传输协议请求；或者接收来自其他服务器转发所述客户端的所述超文本传输协议请求。

在该技术方案中，服务器可以接收来自客户端的超文本传输协议请求，也可以接收来自其他服务器转发客户端的超文本传输协议请求，也就说明本发明中的超文本传输协议请求的处理方法既可以独立进行，也可以嵌入到其他服务器中进行。

本发明的第二方面提出了一种超文本传输协议请求的处理装置，用于服务器，包括：获取单元，用于对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；选择单元，用于根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；处理单元，用于根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。

在该技术方案中，通过对接收到的超文本传输协议请求(即HTTP请求)进行解析，并根据解析结果在超文本传输协议请求中获取统一资源标识符和客户端与服务器的交互类型，其中，客户端与服务器的交互类型包括：读取资源信息(GET)、向服务器提交资源信息(POST)、更新服务器上的资源信息(PUT)、删除服务器上的资源信息(DELETE)、读取资源信息的头部信息(HEAD)、使用WebSocket协议获取资源信息(WS)，从而根据交互类型和统一资源标识符在已定义的多个路由中选择目标路由，其中，已定义的多个路由可以存储在路由文件中，用户可以随时对该路由文件中的多个路由进行修改或增加，进一步地，根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理，因此，通过上述技术方案，避免了相关技术中由于超文本传输协议请求的处理方法直接写在程序源代码中，从而避免了在超文本传输协议请求中的统一资源标识符变化时需要修改程序源代码的繁琐操作，进而使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述技术方案中，优选地，所述选择单元具体用于，在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由；所述选择单元包括：确定单元，用于根据所述至少一个路由确定所述目标路由。

在该技术方案中，通过将多个路由与交互类型和统一资源标识符进行匹配，并根据与交互类型和统一资源标识符匹配的至少一个路由确定目标路由，由于用户可随时对多个路由进行修改或者增加，也就使得在统一资源标识符发生改变时，直接修改多个路由中的统一资源标识符，然后再根据交互类型和变化后的统一资源标识符与多个路由进行匹配来确定目标路由，如此，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述任一技术方案中，优选地，所述选择单元具体用于，在所述多个路由中选择与所述交互类型匹配的路由；所述选择单元还包括：判断单元，用于判断在与所述交互类型匹配的路由中是否存在与所述统一资源标识符匹配的路由，在判断结果为是时，将与所述统一资源标识符匹配的路由作为所述至少一个路由；发送单元，用于在判断结果为否时，构造错误信息，并将所述错误信息发送至所述客户端。

在该技术方案中，若判定在与交互类型匹配的路由中存在与统一资源标识符匹配的路由，则将与统一资源标识符匹配的路由作为至少一个路由，否则，即没有与统一资源标识符匹配的路由，则构造错误信息，并将错误信息发送至客户端，因此，通过上述技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述任一技术方案中，优选地，所述确定单元具体用于，根据所述多个路由的路由规则获取所述至少一个路由的优先级，并将所述至少一个路由中优先级最高的路由作为所述目标路由。

在该技术方案中，根据多个路由的路由规则获取至少一个路由的优先级，例如，根据路由可信度(即管理距离)来确定至少一个路由的优先级(路由的管理距离越小，路由的优先级越高)，然后将至少一个路由中优先级最高的路由作为目标路由，因此，通过上述技术方案，通过选取优先级最高的路由作为目标路由，有效地提升了根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理的可靠性。

在上述任一技术方案中，优选地，还包括：接收单元，用于接收来自所述客户端的所述超文本传输协议请求，或者接收来自其他服务器转发所述客户端的所述超文本传输协议请求。

在该技术方案中，服务器可以接收来自客户端的超文本传输协议请求，也可以接收来自其他服务器转发客户端的超文本传输协议请求，也就说明本发明中的超文本传输协议请求的处理方法既可以独立进行，也可以嵌入到其他服务器中进行。

本发明的第三个方面提出了一种服务器，包括上述技术方案中任一项所述的超文本传输协议请求的处理装置，因此，该服务器具有和上述技术方案中任一项所述的超文本传输协议请求的处理装置相同的技术效果，在此不再赘述。

通过上述技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

附图说明

图1示出了根据本发明的一个实施例的超文本传输协议请求的处理方法的流程示意图；

图2示出了根据本发明的另一个实施例的超文本传输协议请求的处理方法的流程示意图；

图3示出了根据本发明的一个实施例的超文本传输协议请求的处理装置的结构示意图。

图4示出了根据本发明的一个实施例的服务器的结构示意图。

具体实施方式

为了可以更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的一个实施例的超文本传输协议请求的处理方法的流程示意图。

如图1所示，根据本发明的一个实施例的超文本传输协议请求的处理方法，包括：

步骤102，对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；

步骤104，根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；

步骤106，根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。

在该技术方案中，通过对接收到的超文本传输协议请求(即HTTP请求)进行解析，并根据解析结果在超文本传输协议请求中获取统一资源标识符和客户端与服务器的交互类型，其中，客户端与服务器的交互类型包括：读取资源信息(GET)、向服务器提交资源信息(POST)、更新服务器上的资源信息(PUT)、删除服务器上的资源信息(DELETE)、读取资源信息的头部信息(HEAD)、使用WebSocket协议获取资源信息(WS)，从而根据交互类型和统一资源标识符在已定义的多个路由中选择目标路由，其中，已定义的多个路由可以存储在路由文件中，用户可以随时对该路由文件中的多个路由进行修改或增加，进一步地，根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理，因此，通过上述技术方案，避免了相关技术中由于超文本传输协议请求的处理方法直接写在程序源代码中，从而避免了在超文本传输协议请求中的统一资源标识符变化时需要修改程序源代码的繁琐操作，进而使得服务器对超文本传输协议请求的处理更加灵活、简单。

其中，每个路由代表了一个路由的配置项，每一个配置项由客户端与服务器的交互类型、统一资源标识符的模式和业务处理逻辑的动作构成，其中，统一资源标识符的模式定义了超文本传输协议请求的路径，可以是静态值，也可以是基于正则表达式的动态值。例如，路由中的一行配置项为“GET、/clients/aa、admin.Dashboard.index”，其中，GET表示读取资源信息，统一资源标识符的模式是静态模式，值为/clients/aa，业务处理逻辑的动作是admin.Dashboard.index。该配置项的具体含义就是当一个GET方法的超文本传输协议请求发起对资源信息/clients/aa的访问时，交由admin.Dashboard.index处理这个请求并返回结果。再例如，路由文件中的另一行配置项为：POST、/clients/{<[a-z]{4,10}>id}、business.Compute.calc，其中，POST表示向服务器提交资源信息，统一资源标识符的模式是动态模式，其中“{<[a-z]{4,10}>id}”是正则表达式，表示4位到10位的小写字母，并且匹配成功后匹配值命名为id，业务处理逻辑的动作是business.Compute.calc。该配置项的具体含义就是当一个POST方法的超文本传输协议请求发起对资源信息的访问时，交由business.Compute.calc处理这个请求，并且资源的路径由两部分组成，前一部分为clients，后一部分为4位到10位的小写字母。business.Compute.calc在处理请求时会接收到一个名为id的参数，参数值就是资源信息的路径的第二个部分。

在上述技术方案中，优选地，所述步骤104，具体包括：在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由，并根据所述至少一个路由确定所述目标路由。

在该技术方案中，通过将多个路由与交互类型和统一资源标识符进行匹配，并根据与交互类型和统一资源标识符匹配的至少一个路由确定目标路由，由于用户可随时对多个路由进行修改或者增加，也就使得在统一资源标识符发生改变时，直接修改多个路由中的统一资源标识符，然后再根据交互类型和变化后的统一资源标识符与多个路由进行匹配来确定目标路由，如此，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述任一技术方案中，优选地，所述在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由的步骤，具体包括：在所述多个路由中选择与所述交互类型匹配的路由；判断在与所述交互类型匹配的路由中是否存在与所述统一资源标识符匹配的路由；在判断结果为是时，将与所述统一资源标识符匹配的路由作为所述至少一个路由；否则，构造错误信息，并将所述错误信息发送至所述客户端。

在该技术方案中，若判定在与交互类型匹配的路由中存在与统一资源标识符匹配的路由，则将与统一资源标识符匹配的路由作为至少一个路由，否则，即没有与统一资源标识符匹配的路由，则构造错误信息，并将错误信息发送至客户端，因此，通过上述技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

其中，在将多个路由中的与交互类型匹配的路由与解析得到的统一资源标识符进行匹配时，首先将与交互类型匹配的路由分成动态路由和静态路由，静态路由通过匹配字符串的方式与统一资源标识符进行匹配，动态路由与统一资源标识符进行模式上的匹配，而且动态路由进行正则表达式的处理，正则表达式又称正规表示法、常规表示法(RegularExpression，在代码中常简写为regex、regexp或RE)，正则表达式使用单个字符串来描述、匹配一系列符合某个句法规则的字符串。

在上述任一技术方案中，优选地，若所述至少一个路由的数量为多个，则根据所述至少一个路由确定所述目标路由的步骤，具体包括：根据所述多个路由的路由规则获取所述至少一个路由的优先级；将所述至少一个路由中优先级最高的路由作为所述目标路由。

在该技术方案中，根据多个路由的路由规则获取至少一个路由的优先级，例如，根据路由可信度(即管理距离)来确定至少一个路由的优先级(路由的管理距离越小，路由的优先级越高)，然后将至少一个路由中优先级最高的路由作为目标路由，因此，通过上述技术方案，通过选取优先级最高的路由作为目标路由，有效地提升了根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理的可靠性。

在上述任一技术方案中，优选地，步骤102之前，包括：接收来自所述客户端的所述超文本传输协议请求；或者接收来自其他服务器转发所述客户端的所述超文本传输协议请求。

在该技术方案中，服务器可以接收来自客户端的超文本传输协议请求，也可以接收来自其他服务器转发客户端的超文本传输协议请求，也就说明本发明中的超文本传输协议请求的处理方法既可以独立进行，也可以嵌入到其他服务器中进行。

图2示出了根据本发明的另一个实施例的超文本传输协议请求的处理方法的流程示意图。

如图2所示，根据本发明的另一个实施例的超文本传输协议请求的处理方法，包括：

步骤202，对HTTP请求进行解析，以根据解析结果获取HTTP请求中的HTTP方法(即服务器与客户端的交互类型)和URI；

步骤204，读取路由文件；

步骤206，将HTTP方法与路由文件中的多个路由进行匹配；

步骤208，判断在与HTTP方法匹配的路由中是否存在与URI匹配的路由，在判定结果为是时，进入步骤212，否则，进入步骤210；

步骤210，构造错误信息，并将错误信息发送至客户端；

步骤212，将与URI匹配的路由作为至少一个路由，并在至少一个路由中选择目标路由。

图3示出了根据本发明的一个实施例的超文本传输协议请求的处理装置的结构示意图。

如图3所示，根据本发明的一个实施例的超文本传输协议请求的处理装置300，包括：获取单元302，选择单元304和处理单元306，其中，所述获取单元302，用于对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；所述选择单元304，用于根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；所述处理单元306，用于根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。

在该技术方案中，通过对接收到的超文本传输协议请求(即HTTP请求)进行解析，并根据解析结果在超文本传输协议请求中获取统一资源标识符和客户端与服务器的交互类型，其中，客户端与服务器的交互类型包括：读取资源信息(GET)、向服务器提交资源信息(POST)、更新服务器上的资源信息(PUT)、删除服务器上的资源信息(DELETE)、读取资源信息的头部信息(HEAD)、使用WebSocket协议获取资源信息(WS)，从而根据交互类型和统一资源标识符在已定义的多个路由中选择目标路由，其中，已定义的多个路由可以存储在路由文件中，用户可以随时对该路由文件中的多个路由进行修改或增加，进一步地，根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理，因此，通过上述技术方案，避免了相关技术中由于超文本传输协议请求的处理方法直接写在程序源代码中，从而避免了在超文本传输协议请求中的统一资源标识符变化时需要修改程序源代码的繁琐操作，进而使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述技术方案中，优选地，所述选择单元304具体用于，在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由；所述选择单元304包括：确定单元3042，用于根据所述至少一个路由确定所述目标路由。

在该技术方案中，通过将多个路由与交互类型和统一资源标识符进行匹配，并根据与交互类型和统一资源标识符匹配的至少一个路由确定目标路由，由于用户可随时对多个路由进行修改或者增加，也就使得在统一资源标识符发生改变时，直接修改多个路由中的统一资源标识符，然后再根据交互类型和变化后的统一资源标识符与多个路由进行匹配来确定目标路由，如此，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

在上述任一技术方案中，优选地，所述选择单元304具体用于，在所述多个路由中选择与所述交互类型匹配的路由；所述选择单元304还包括：判断单元3044，用于判断在与所述交互类型匹配的路由中是否存在与所述统一资源标识符匹配的路由，在判断结果为是时，将与所述统一资源标识符匹配的路由作为所述至少一个路由；发送单元3046，用于在判断结果为否时，构造错误信息，并将所述错误信息发送至所述客户端。

在该技术方案中，若判定在与交互类型匹配的路由中存在与统一资源标识符匹配的路由，则将与统一资源标识符匹配的路由作为至少一个路由，否则，即没有与统一资源标识符匹配的路由，则构造错误信息，并将错误信息发送至客户端，因此，通过上述技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

其中，在将多个路由中的与交互类型匹配的路由与解析得到的统一资源标识符进行匹配时，首先将与交互类型匹配的路由分成动态路由和静态路由，静态路由通过匹配字符串的方式与统一资源标识符进行匹配，动态路由与统一资源标识符进行模式上的匹配，而且动态路由进行正则表达式的处理，正则表达式又称正规表示法、常规表示法(RegularExpression，在代码中常简写为regex、regexp或RE)，正则表达式使用单个字符串来描述、匹配一系列符合某个句法规则的字符串。

在上述任一技术方案中，优选地，所述确定单元3042具体用于，根据所述多个路由的路由规则获取所述至少一个路由的优先级，并将所述至少一个路由中优先级最高的路由作为所述目标路由。

在该技术方案中，根据多个路由的路由规则获取至少一个路由的优先级，例如，根据路由可信度(即管理距离)来确定至少一个路由的优先级(路由的管理距离越小，路由的优先级越高)，然后将至少一个路由中优先级最高的路由作为目标路由，因此，通过上述技术方案，通过选取优先级最高的路由作为目标路由，有效地提升了根据目标路由中业务处理逻辑的动作对超文本传输协议请求进行处理的可靠性。

在上述任一技术方案中，优选地，还包括：接收单元308，用于接收来自所述客户端的所述超文本传输协议请求，或者接收来自其他服务器转发所述客户端的所述超文本传输协议请求。

在该技术方案中，服务器可以接收来自客户端的超文本传输协议请求，也可以接收来自其他服务器转发客户端的超文本传输协议请求，也就说明本发明中的超文本传输协议请求的处理方法既可以独立进行，也可以嵌入到其他服务器中进行。

图4示出了根据本发明的一个实施例的服务器的结构示意图。

如图4所示，根据本发明的一个实施例的服务器400，包括：包括上述技术方案中任一项所述的超文本传输协议请求的处理装置300，因此，该服务器400具有和上述技术方案中任一项所述的超文本传输协议请求的处理装置300相同的技术效果，在此不再赘述。

以上结合附图详细说明了本发明的技术方案，可以使得服务器对超文本传输协议请求的处理更加灵活、简单。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (11)

1.一种超文本传输协议请求的处理方法，用于服务器，其特征在于，包括：

对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；

根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；

根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。

2.根据权利要求1所述的超文本传输协议请求的处理方法，其特征在于，所述根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由的步骤，具体包括：

在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由，并根据所述至少一个路由确定所述目标路由。

3.根据权利要求2所述的超文本传输协议请求的处理方法，其特征在于，所述在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由的步骤，具体包括：

在所述多个路由中选择与所述交互类型匹配的路由；

判断在与所述交互类型匹配的路由中是否存在与所述统一资源标识符匹配的路由；

在判断结果为是时，将与所述统一资源标识符匹配的路由作为所述至少一个路由；

否则，构造错误信息，并将所述错误信息发送至所述客户端。

4.根据权利要求2所述的超文本传输协议请求的处理方法，其特征在于，若所述至少一个路由的数量为多个，则根据所述至少一个路由确定所述目标路由的步骤，具体包括：

根据所述多个路由的路由规则获取所述至少一个路由的优先级；

将所述至少一个路由中优先级最高的路由作为所述目标路由。

5.根据权利要求1至4中任一项所述的超文本传输协议请求的处理方法，其特征在于，所述对接收到的超文本传输协议请求进行解析的步骤之前，包括：

接收来自所述客户端的所述超文本传输协议请求；或者

接收来自其他服务器转发所述客户端的所述超文本传输协议请求。

6.一种超文本传输协议请求的处理装置，用于服务器，其特征在于，包括：

获取单元，用于对接收到的超文本传输协议请求进行解析，并根据解析结果在所述超文本传输协议请求中获取统一资源标识符和客户端与所述服务器的交互类型；

选择单元，用于根据所述交互类型和所述统一资源标识符，在已定义的多个路由中选择目标路由；

处理单元，用于根据所述目标路由中业务处理逻辑的动作，对所述超文本传输协议请求进行处理。

7.根据权利要求6所述的超文本传输协议请求的处理装置，其特征在于，

所述选择单元具体用于，在所述多个路由中选择与所述交互类型和所述统一资源标识符匹配的至少一个路由；

所述选择单元包括：

确定单元，用于根据所述至少一个路由确定所述目标路由。

8.根据权利要求7所述的超文本传输协议请求的处理装置，其特征在于，

所述选择单元具体用于，在所述多个路由中选择与所述交互类型匹配的路由；

所述选择单元还包括：

判断单元，用于判断在与所述交互类型匹配的路由中是否存在与所述统一资源标识符匹配的路由，在判断结果为是时，将与所述统一资源标识符匹配的路由作为所述至少一个路由；

发送单元，用于在判断结果为否时，构造错误信息，并将所述错误信息发送至所述客户端。

9.根据权利要求7所述的超文本传输协议请求的处理装置，其特征在于，所述确定具体用于，

根据所述多个路由的路由规则获取所述至少一个路由的优先级，并将所述至少一个路由中优先级最高的路由作为所述目标路由。

10.根据权利要求6至9中任一项所述的超文本传输协议请求的处理装置，其特征在于，还包括：

接收单元，用于接收来自所述客户端的所述超文本传输协议请求，或者接收来自其他服务器转发所述客户端的所述超文本传输协议请求。

11.一种服务器，其特征在于，包括：如权利要求6至10中任一项所述的超文本传输协议请求的处理装置。