CN114285834A - 一种报文传输方法、装置及终端设备 - Google Patents

Abstract

本申请提供一种报文传输方法、装置及终端设备。该方法包括：获取待发送的第一请求报文；其中，第一请求报文符合RESTful API规范；在确定第一请求报文的请求方法为GET时，对第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在请求URL字段；当第一请求报文中的请求URL字段的长度大于预设长度时，将第一请求报文转换为第二请求报文；其中，第二请求报文与第一请求报文的请求方法不同，GET请求数据填充在第二请求报文的消息主体中；第二请求报文中的请求头域中配置预设字符；预设字符用于表征第二请求报文为转换后的报文；将第二请求报文发送至服务器。通过上述方式能够避免请求方法为GET的报文因请求URL字段过长导致该请求无法发送的问题。

Description

一种报文传输方法、装置及终端设备

技术领域

本申请涉及通信技术领域，具体而言，涉及一种报文传输方法、装置及终端设备。

背景技术

HTTP协议(Hyper Text Transfer Protocol，超文本传输协议)是一种分布式、合作式、多媒体信息系统服务、面向应用层的协议。一个HTTP请求通常包括：请求URI(UniformResource Identifier，统一资源标识符)、请求方法、请求头域、消息主体。

一个web(World Wide Web，全球广域网)服务可以分为前端和后端。前后端之间使用基于HTTP协议的API(Application Programming Interface，应用程序编程接口)接口进行交互通信，最终提供完整的服务。

RESTful(Representational State Transfer，表征性状态转移)API是目前比较成熟的一套互联网应用程序的API设计规范。在RESTful API中，对于资源的具体操作类型，由请求方法表示。常用的请求方法有：GET、POST、PUT、DELETE等，每个请求方法表示特定的操作类型，如GET表示获取数据请求；POST表示新增数据请求；PUT表示修改数据请求；DELETE表示删除数据请求。

然而，发明人在实际研究中发现，在基于RESTful API规范的项目中由于GET请求报文没有消息主体，请求携带的数据通常放在请求URI中，进而使得请求URI字段过长。而主流的浏览器和服务器对于GET请求的请求URI字段长度均有限制，超出限制之后会返回错误码414(表征请求URI字段过长)，进而导致前端无法向后端请求获取数据。

发明内容

本申请实施例的目的在于提供一种报文传输方法、装置及终端设备，以改善“在基于RESTful API规范的项目中由于GET请求将携带的数据放在请求URI中，会使得请求URI过长，导致对于GET请求的请求URI字段长度均有限制的主流的浏览器和服务器返回错误码”的问题。

本发明是这样实现的：

第一方面，本申请实施例提供一种报文传输方法，应用于终端设备，所述方法包括：获取待发送的第一请求报文；其中，所述第一请求报文符合RESTful API规范；在确定所述第一请求报文的请求方法为GET时，对所述第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在所述请求URL字段；当所述第一请求报文中的请求URL字段的长度大于预设长度时，将所述第一请求报文转换为第二请求报文；其中，所述第二请求报文与所述第一请求报文的请求方法不同，所述GET请求数据填充在所述第二请求报文的消息主体中；所述第二请求报文中的请求头域中配置预设字符；所述预设字符用于表征所述第二请求报文为转换后的报文；将所述第二请求报文发送至服务器。

在本申请实施例中，终端设备在获取到待发送的第一请求报文后，且确定该报文的请求方法为GET时，会对该报文中的请求URL字段的长度进行校验，当请求URL字段的长度大于预设长度时，将该报文进行转换。转换后得到的第二请求报文与第一请求报文的请求方法不同，GET请求数据填充在第二请求报文的消息主体中；第二请求报文中的请求头域中配置预设字符，以便后续服务器基于预设字符确定该报文为经转换后的报文。通过上述方式能够避免GET请求报文因请求URL字段过长导致该请求无法发送的问题，并且通过预设字符也能够使得服务器进行识别，避免出现报文交互过程中造成的语义混淆，操作与请求不匹配的问题。此外，由于GET请求数据可以填充在消息主体中，后续也能够对消息主体的信息进行加密传输，进而提高安全性。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述将所述第一请求报文转换为第二请求报文，包括：将所述第一请求报文的请求方法更改为第一方法；将所述GET请求数据转移至更改请求方法后的报文的消息主体中；在所述更改请求方法后的报文的请求头域中配置所述预设字符，进而得到所述第二请求报文。

在报文转换时，终端设备将第一请求报文的请求方法更改为第一方法，进而将GET请求数据转移至更改请求方法后的报文的消息主体中，由于GET请求数据可以填充在消息主体中，后续也能够对消息主体的信息进行加密传输，进而提高安全性。同时，在更改请求方法后的报文的请求头域中配置预设字符，使得服务器能够进行识别，避免出现报文交互过程中造成的语义混淆，操作与请求不匹配的问题。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述预设字符为GET。

在本申请实施例中，当预设字符为GET时，使得服务器能够在识别出到GET字符后，直接将报文确定还原为GET请求报文。

结合上述第一方面提供的技术方案，在一些可能的实现方式中，所述方法还包括：当所述第一请求报文中的请求URL字段的长度小于预设长度时，将所述第一请求报文发送至服务器。

在本申请实施例中，当第一请求报文中的请求URL字段的长度小于预设长度时，将第一请求报文直接发送至服务器，以实现报文的快速发送。

第二方面，本申请实施例还提供一种报文传输方法，应用于服务器，所述方法包括：接收终端设备发送的第三请求报文；其中，所述第三请求报文符合RESTful API规范；在确定所述第三请求报文的请求头域中配置有预设字符时，将所述第三请求报文还原为第四请求报文；其中，所述第四请求报文的请求方法为GET；所述第四请求报文的请求URL字段填充有GET请求数据，所述第四请求报文中的请求头域不包括所述预设字符；基于所述第四请求报文进行处理。

在本申请实施例中，服务器在接收到第三请求报文，且确定第三请求报文的请求头域中配置有预设字符时，将第三请求报文还原为第四请求报文。通过上述方式能够避免请求方法为GET的报文因请求URL字段过长导致服务器返回错误码的问题，并且通过预设字符也能够使得服务器进行识别，避免出现报文交互过程中造成的语义混淆，操作与请求不匹配的问题。

结合上述第二方面提供的技术方案，在一些可能的实现方式中，所述将所述第三请求报文还原为第四请求报文，包括：将所述第三请求报文的请求方法更改为GET；将所述GET请求数据转移至更改请求方法后的报文的请求URL字段中；将所述更改请求方法后的报文的请求头域中配置的所述预设字符删除，进而得到所述第四请求报文。

在报文还原的过程中，服务器将第三请求报文的请求方法更改为GET，然后，将GET请求数据转移至更改请求方法后的报文的请求URL字段中；再将更改请求方法后的报文的请求头域中配置的预设字符删除，进而将第三请求报文还原为GET请求报文，以便于服务器基于GET请求报文进行相应的业务处理。

结合上述第二方面提供的技术方案，在一些可能的实现方式中，在所述确定所述第三请求报文的请求头域中配置有预设字符之前，所述方法还包括：确定所述第三请求报文的请求方法为第二方法。

在本申请实施例中，只有当确定第三请求报文的请求为第二方法，才会对请求头域进行解析以及后续的报文还原，通过该方式能够提高服务器的处理效率，以及减小处理器的处理压力。

第三方面，本申请实施例提供一种报文传输装置，配置于终端设备，所述装置包括：请求拦截模块，用于获取待发送的第一请求报文；其中，所述第一请求报文符合RESTfulAPI规范；及在确定所述第一请求报文的请求方法为GET时，对所述第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在所述请求URL字段；请求方法转换模块，用于当所述第一请求报文中的请求URL字段的长度大于预设长度时，将所述第一请求报文转换为第二请求报文；其中，所述第二请求报文与所述第一请求报文的请求方法不同，所述GET请求数据填充在所述第二请求报文的消息主体中；所述第二请求报文中的请求头域中配置预设字符；所述预设字符用于表征所述第二请求报文为转换后的报文；请求发送模块，用于将所述第二请求报文发送至服务器。

第四方面，本申请实施例提供一种报文传输装置，配置于服务器，所述装置包括：请求接收模块，用于接收终端设备发送的第三请求报文；请求方法还原模块，在确定所述第三请求报文的请求头域中配置有预设字符时，将所述第三请求报文还原为第四请求报文；其中，所述第四请求报文的请求方法为GET；所述第四请求报文的请求URL字段填充GET请求数据，所述第四请求报文中的请求头域不包括所述预设字符；业务处理模块，用于基于所述第四请求报文进行处理。

第五方面，本申请实施例提供一种终端设备，包括：处理器和存储器，所述处理器和所述存储器连接；所述存储器用于存储程序；所述处理器用于调用存储在所述存储器中的程序，执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式提供的方法。

第六方面，本申请实施例提供一种服务器，包括：处理器和存储器，所述处理器和所述存储器连接；所述存储器用于存储程序；所述处理器用于调用存储在所述存储器中的程序，执行如上述第二方面实施例和/或结合上述第二方面实施例的一些可能的实现方式提供的方法。

第七方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被处理器运行时执行如上述第一方面实施例和/或结合上述第一方面实施例的一些可能的实现方式提供的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种网络系统的结构框图。

图2为本申请实施例提供的一种终端设备的模块框图。

图3为本申请实施例提供的一种应用于终端设备的报文传输方法的步骤流程图。

图4为本申请实施例提供的一种应用于服务器的报文传输方法的步骤流程图。

图5为本申请实施例提供的一种配置于终端设备的报文传输装置的模块框图。

图6为本申请实施例提供的一种配置于服务器的报文传输装置的模块框图。

图标：10-网络系统；100-终端设备；110-处理器；120-存储器；200-服务器；310-请求拦截模块；320-请求方法转换模块；330-请求发送模块；410-请求接收模块；420-请求方法还原模块；430-业务处理模块。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

请参阅图1，本申请实施例提供一种网络系统10，包括终端设备100及与终端设备100通信连接的服务器200。

其中，终端设备100可以通过使用基于HTTP协议的API接口与服务器200进行交互，以使得服务器200提供相应的服务。终端设备100可以是但不限于个人计算机(PersonalComputer，PC)、智能手机、平板电脑、个人数字助理(Personal Digital Assistant，PDA)、移动上网设备(Mobile Internet Device，MID)等。

请参阅图2，图2为本申请实施例提供的一种应用报文传输方法及装置的终端设备100的示意性结构框图。在结构上，终端设备100可以包括处理器110和存储器120。

处理器110与存储器120直接或间接地电性连接，以实现数据的传输或交互，例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。报文传输装置包括至少一个可以软件或固件(Firmware)的形式存储在存储器120中或固化在终端设备100的操作系统(Operating System，OS)中的软件模块。处理器110用于执行存储器120中存储的可执行模块，例如，报文传输装置所包括的软件功能模块及计算机程序等，以实现报文传输方法。处理器110可以在接收到执行指令后，执行计算机程序。

其中，处理器110可以是一种集成电路芯片，具有信号处理能力。处理器110也可以是通用处理器，例如，可以是中央处理器(Central Processing Unit，CPU)、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific IntegratedCircuit，ASIC)、分立门或晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。此外，通用处理器可以是微处理器或者任何常规处理器等。

存储器120可以是，但不限于，随机存取存储器(Random Access Memory，RAM)、只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-OnlyMemory，PROM)、可擦可编程序只读存储器(Erasable Programmable Read-Only Memory，EPROM)，以及电可擦编程只读存储器(Electric Erasable Programmable Read-OnlyMemory，EEPROM)。存储器120用于存储程序，处理器110在接收到执行指令后，执行该程序。

需要说明的是，图1所示的结构仅为示意，本申请实施例提供的终端设备100还可以具有比图1更少或更多的组件，或是具有与图1所示不同的配置。此外，图1所示的各组件可以通过软件、硬件或其组合实现。

上述的服务器可以是但不限于网络服务器、数据库服务器、云服务器或由多个子服务器构成的服务器集成等。当然，上述列举的设备仅用于便于理解本申请实施例，其不应作为对本实施例的限定。在结构上，服务器也可以包括处理器和存储器。服务器的具体结构可以参考图2及上述实施例中的说明，为了避免累赘，此处不作赘述。

请参阅图3，图3为本申请实施例提供的报文传输方法的步骤流程图，该方法应用于图2所示的终端设备100。需要说明的是，本申请实施例提供的报文传输方法不以图3及以下所示的顺序为限制，该方法包括：步骤S101-步骤S104。

步骤S101：获取待发送的第一请求报文；其中，第一请求报文符合RESTful API规范。

本申请实施例所提供的报文传输方法可以通过工具包、插件等方式配置于终端设备中。工具包、插件可以用于拦截终端设备待发送的第一请求报文，进而对第一请求报文进行解析处理。

以工具包为例，工具包中配置参数可以包括：原始请求方法、转换后的请求方法、原始请求方法的请求URL字段的预设长度。

其中，原始请求方法表征需要进行报文转换的请求方法，于本申请实施例中，原始请求方法为GET。转换后的请求方法可以是但不限于POST、PUT。原始请求方法的请求URL字段的预设长度可以根据浏览器的不同进行选择，比如预设长度可以取当前各个主流浏览器限制的最小值(如最小值为2083)。

步骤S102：在确定第一请求报文的请求方法为GET时，对第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在请求URL字段。

由于工具包中预先配置有原始请求方法及原始请求方法的请求URL字段的预设长度。因此，在确定第一请求报文的请求方法为原始请求方法，即GET时，对第一请求报文进行解析，进而对第一请求报文中的请求URL字段的长度进行校验，以根据第一请求报文中的请求URL字段的长度确定是否需要对第一请求报文进行报文转换。需要说明的是，在基于RESTful API规范的项目中GET请求报文没有消息主体。

步骤S103：当第一请求报文中的请求URL字段的长度大于预设长度时，将第一请求报文转换为第二请求报文；其中，第二请求报文与第一请求报文的请求方法不同，GET请求数据填充在第二请求报文的消息主体中；第二请求报文中的请求头域中配置预设字符；预设字符用于表征第二请求报文为转换后的报文。

当第一请求报文中的请求URL字段的长度大于预设长度时，则表征第一请求报文有可能不会被主流的浏览器和服务器进行处理，进而返回错误码。因此，此时对第一请求报文进行转换。

报文转换的具体步骤包括：将第一请求报文的请求方法更改为第一方法；将GET请求数据转移至更改请求方法后的报文的消息主体中；在更改请求方法后的报文的请求头域中配置预设字符，进而得到第二请求报文。

由于工具包中预先配置有转换后的请求方法，因此，根据配置的转换后的请求方法，将第一请求报文的请求方法更改为第一方法。示例性的，转换后的请求方法为POST，则将第一请求报文的请求方法更改为POST。其中，POST即为第一方法。

当然，转换后的请求方法还可以为PUT，相应的，第一方法即为PUT。

以请求方法为POST为例，由于请求方法为POST的报文包括消息主体，因此，此时，将GET请求数据从请求URL字段转移至消息主体中。比如，可以先将GET请求数据放入消息主体中，再将请求URL字段中的GET请求数据移除。最后，再将更改请求方法后的报文的请求头域中配置预设字符，即可完报文的转换，转换后的报文为第二请求报文。

需要说明的是，预设字符以使得后续服务器能够识别出该报文为转换后的报文。于本申请实施例中，预设字符可以具体为GET，以便于服务器知悉报文转换前的请求方法为GET。通过该方式能够使得后续服务器在识别出到GET字符后，直接将报文确定还原为GET请求报文。

此外，上述的预设字符也可以任意配置，比如某个英文字符或者阿拉伯数字，对此，本申请不作限定。

步骤S104：将第二请求报文发送至服务器。

在转换完成后，终端设备将转换后生成的第二请求报文发送至服务器。

综上，在本申请实施例中，终端设备在获取到待发送的第一请求报文后，且确定该报文的请求方法为GET时，会对该报文中的请求URL字段的长度进行校验，当请求URL字段的长度大于预设长度时，将该报文进行转换。转换后得到的第二请求报文与所述第一请求报文的请求方法不同，GET请求数据填充在第二请求报文的消息主体中；第二请求报文中的请求头域中配置预设字符，以便后续服务器基于预设字符确定该报文为经转换后的报文。通过上述方式能够避免GET请求报文因请求URL字段过长导致该请求无法发送的问题，并且通过预设字符也能够使得服务器进行识别，避免出现报文交互过程中造成的语义混淆，操作与请求不匹配的问题。此外，由于GET请求数据可以填充在消息主体中，后续也能够对消息主体的信息进行加密传输，进而提高安全性。

此外，当第一请求报文中的请求URL字段的长度小于预设长度时，终端设备可以直接将第一请求报文发送至服务器，进而实现报文的快速发送。

下面再对服务器接收报文后的处理流程进行说明，请参阅图4，图4为本申请实施例提供的一种应用于服务器中的报文传输方法的步骤流程图。需要说明的是，本申请实施例提供的报文传输方法不以图4及以下所示的顺序为限制，该方法包括：步骤S201-步骤S203。

步骤S201：接收终端设备发送的第三请求报文；其中，第三请求报文符合RESTfulAPI规范。

同理，本申请实施例所提供的报文传输方法可以通过工具包、插件等方式配置于服务器中。工具包可以拦截服务器接收到的第三请求报文，进而对第三请求报文进行解析处理。

以工具包为例，工具包中配置参数可以包括：还原后的请求方法。于本申请实施例中，还原后的请求方法为GET。

步骤S202：在确定第三请求报文的请求头域中配置有预设字符时，将第三请求报文还原为第四请求报文；其中，第四请求报文的请求方法为GET；第四请求报文的请求URL字段填充有GET请求数据，第四请求报文中的请求头域不包括预设字符。

在对第三请求报文进行解析，发现请求头域中配置有预设字符后，将第三请求报文进行还原。

一实施例中，预设字符为某个英文字符或者阿拉伯数字。此时，在解析到请求头域中包括某个英文字符或者阿拉伯数字后，直接将第三请求报文进行还原。

又一实施例中，预设字符为GET，此时，工具包确定自身配置的还原后的请求方法与预设字符是否相同，若均为GET，则将第三请求报文进行还原。

此外，在确定第三请求报文的请求头域中配置有预设字符之前，该方法还包括：确定第三请求报文的请求方法为第二方法。

也即，工具包中还配置有还原前的请求方法，即第二方法。

示例性的，还原前的请求方法为POST，则工具包在拦截到第三请求报文后，先确定第三请求报文的请求方法是否为POST，若是，再执行后续的解析还原等操作，若否，则直接通过服务器对第三请求报文进行业务逻辑处理。

当然，还原前的请求方法，即第二方法还可以是但不限于PUT，对此，本申请不作限定。

可见，在本申请实施例中，只有当确定第三请求报文的请求为第二方法，才会对请求头域进行解析以及后续的报文还原，通过该方式能够提高服务器的处理效率，以及减小处理器的处理压力。

上述报文还原的具体步骤包括：将第三请求报文的请求方法更改为GET；将GET请求数据转移至更改请求方法后的报文的请求URL字段中；将更改请求方法后的报文的请求头域中配置的预设字符删除，进而得到第四请求报文。

首先，将第三请求报文的请求方法更改为GET。由于请求方法为GET的报文不包括消息主体，因此，将GET请求数据转移至更改请求方法后的报文的请求URL字段中。最后将更改请求方法后的报文的请求头域中配置的预设字符删除，即可得到第四请求报文，第四请求报文即为GET请求对应的报文。

步骤S203：基于第四请求报文进行处理。

在报文还原之后，即可通过服务器对第四请求报文进行业务逻辑处理，即处理终端设备的GET请求。

综上，在本申请实施例中，服务器在接收到第三请求报文，且确定第三请求报文的请求头域中配置有预设字符时，将第三请求报文还原为第四请求报文。通过上述方式能够避免请求方法为GET的报文因请求URL字段过长导致服务器返回错误码的问题，并且通过预设字符也能够使得服务器进行识别，避免出现报文交互过程中造成的语义混淆，操作与请求不匹配的问题。

下面结合一个完整的示例对本申请实施例提供的报文传输方法进行说明。

终端设备若需要发送请求报文A，其中，请求报文A的请求方法为GET。则终端设备首先判断请求报文A中的第一请求报文中的请求URL字段的长度是否大于预设长度，当第一请求报文中的请求URL字段的长度是否大于预设长度时，终端设备将请求报文A进行转换。具体的，第一步，将报文的请求方法更改为POST；第二步，将GET请求数据放入消息主体中；第三步，将原先配置在请求URL字段的GET请求数据移除；第四步，将请求头域中配置预设字符GET，进而得到请求报文B。最后，终端设备将请求报文B发送至服务器。

服务器在接收到请求报文B之后，首先判断该报文的请求方法是否为POST，若是，则对该报文进行解析，判断自身配置的还原后的请求方法与预设字符GET是否相同，若相同，此时，对请求报文B进行还原。具体的，第一步，将请求报文B的请求方法更改为GET；第二步，将GET请求数据转移至请求URL字段中；第三步，将更改请求方法后的报文的请求头域中配置的预设字符删除，即可得到请求报文A。最后，服务器根据请求报文A执行对应的业务逻辑处理。

在处理完成后，服务器向终端设备发送响应报文。需要说明的是，响应报文无需进行报文的转换或还原。

此外，由于GET请求数据可以填充在消息主体中，后续也能够对消息主体的信息进行加密传输，进而提高安全性。此时，终端设备与服务器中会预先配制相同的加解密规则，对此，本申请不作限定。

请参阅图5，基于同一发明构思，本申请实施例还提供一种报文传输装置，该装置配置于终端设备，该装置包括：

请求拦截模块310，用于获取待发送的第一请求报文；其中，所述第一请求报文符合RESTful API规范；及在确定所述第一请求报文的请求方法为GET时，对所述第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在所述请求URL字段。

请求方法转换模块320，用于当所述第一请求报文中的请求URL字段的长度大于预设长度时，将所述第一请求报文转换为第二请求报文；其中，所述第二请求报文与所述第一请求报文的请求方法不同，所述GET请求数据填充在所述第二请求报文的消息主体中；所述第二请求报文中的请求头域中配置预设字符；所述预设字符用于表征所述第二请求报文为转换后的报文。

请求发送模块330，用于将所述第二请求报文发送至服务器。

可选地，请求方法转换模块320具体用于将所述第一请求报文的请求方法更改为第一方法；将所述GET请求数据转移至更改请求方法后的报文的消息主体中；在所述更改请求方法后的报文的请求头域中配置所述预设字符，进而得到所述第二请求报文。

可选地，请求发送模块330还用于当所述第一请求报文中的请求URL字段的长度小于预设长度时，将所述第一请求报文发送至服务器。

请参阅图6，基于同一发明构思，本申请实施例还提供一种报文传输装置，该装置配置于服务器，该装置包括：

请求接收模块410，用于接收终端设备发送的第三请求报文。

请求方法还原模块420，用于在确定所述第三请求报文的请求头域中配置有预设字符时，将所述第三请求报文还原为第四请求报文；其中，所述第四请求报文的请求方法为GET；所述第四请求报文的请求URL字段填充GET请求数据，所述第四请求报文中的请求头域不包括所述预设字符。

业务处理模块430，用于基于所述第四请求报文进行处理。

可选地，请求方法还原模块420具体用于将所述第三请求报文的请求方法更改为GET；将所述GET请求数据转移至更改请求方法后的报文的请求URL字段中；将所述更改请求方法后的报文的请求头域中配置的所述预设字符删除，进而得到所述第四请求报文。

可选地，请求方法还原模块420还用于在所述确定所述第三请求报文的请求头域中配置有预设字符之前，确定所述第三请求报文的请求方法为第二方法。

需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

基于同一发明构思，本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序在被运行时执行上述实施例中提供的方法。

该存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。

在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。

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

Claims (10)

1.一种报文传输方法，其特征在于，应用于终端设备，所述方法包括：

获取待发送的第一请求报文；其中，所述第一请求报文符合RESTful API规范；

在确定所述第一请求报文的请求方法为GET时，对所述第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在所述请求URL字段；

当所述第一请求报文中的请求URL字段的长度大于预设长度时，将所述第一请求报文转换为第二请求报文；其中，所述第二请求报文与所述第一请求报文的请求方法不同，所述GET请求数据填充在所述第二请求报文的消息主体中；所述第二请求报文中的请求头域中配置预设字符；所述预设字符用于表征所述第二请求报文为转换后的报文；

将所述第二请求报文发送至服务器。

2.根据权利要求1所述的方法，其特征在于，所述将所述第一请求报文转换为第二请求报文，包括：

将所述第一请求报文的请求方法更改为第一方法；

将所述GET请求数据转移至更改请求方法后的报文的消息主体中；

在所述更改请求方法后的报文的请求头域中配置所述预设字符，进而得到所述第二请求报文。

3.根据权利要求1-2任一项所述的方法，其特征在于，所述预设字符为GET。

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

当所述第一请求报文中的请求URL字段的长度小于预设长度时，将所述第一请求报文发送至服务器。

5.一种报文传输方法，其特征在于，应用于服务器，所述方法包括：

接收终端设备发送的第三请求报文；其中，所述第三请求报文符合RESTful API规范；

在确定所述第三请求报文的请求头域中配置有预设字符时，将所述第三请求报文还原为第四请求报文；其中，所述第四请求报文的请求方法为GET；所述第四请求报文的请求URL字段填充有GET请求数据，所述第四请求报文中的请求头域不包括所述预设字符；

基于所述第四请求报文进行处理。

6.根据权利要求5所述的方法，其特征在于，所述将所述第三请求报文还原为第四请求报文，包括：

将所述第三请求报文的请求方法更改为GET；

将所述GET请求数据转移至更改请求方法后的报文的请求URL字段中；

将所述更改请求方法后的报文的请求头域中配置的所述预设字符删除，进而得到所述第四请求报文。

7.根据权利要求6所述的方法，其特征在于，在所述确定所述第三请求报文的请求头域中配置有预设字符之前，所述方法还包括：

确定所述第三请求报文的请求方法为第二方法。

8.一种报文传输装置，其特征在于，配置于终端设备，所述装置包括：

请求拦截模块，用于获取待发送的第一请求报文；其中，所述第一请求报文符合RESTful API规范；及在确定所述第一请求报文的请求方法为GET时，对所述第一请求报文中的请求URL字段的长度进行校验；其中，GET请求数据填充在所述请求URL字段；

请求方法转换模块，用于当所述第一请求报文中的请求URL字段的长度大于预设长度时，将所述第一请求报文转换为第二请求报文；其中，所述第二请求报文与所述第一请求报文的请求方法不同，所述GET请求数据填充在所述第二请求报文的消息主体中；所述第二请求报文中的请求头域中配置预设字符；所述预设字符用于表征所述第二请求报文为转换后的报文；

请求发送模块，用于将所述第二请求报文发送至服务器。

9.一种报文传输装置，其特征在于，配置于服务器，所述装置包括：

请求接收模块，用于接收终端设备发送的第三请求报文；

请求方法还原模块，用于在确定所述第三请求报文的请求头域中配置有预设字符时，将所述第三请求报文还原为第四请求报文；其中，所述第四请求报文的请求方法为GET；所述第四请求报文的请求URL字段填充GET请求数据，所述第四请求报文中的请求头域不包括所述预设字符；

业务处理模块，用于基于所述第四请求报文进行处理。

10.一种终端设备，其特征在于，包括：处理器和存储器，所述处理器和所述存储器连接；

所述存储器用于存储程序；

所述处理器用于运行存储在所述存储器中的程序，执行如权利要求1-4中任一项所述的方法。

Images