restclient和REST控制台都不支持这一点，但curl支持。

HTTP规范在第4.3节中说明

如果请求方法规范（第5.1.1节）不允许在请求中发送实体体，则请求中不得包含消息体。

第5.1.1节将我们重定向到第9.x节以了解各种方法。它们都没有明确禁止包含消息体。然而

第5.2节规定

通过检查请求URI和主机头字段来确定由Internet请求标识的确切资源。

第9.3节规定

GET方法意味着检索请求URI标识的任何信息（以实体的形式）。

这一起表明，在处理GET请求时，服务器不需要检查除请求URI和主机头字段之外的任何内容。

总之，HTTP规范不会阻止您使用GET发送消息体，但存在足够的歧义，如果不是所有服务器都支持它，我不会感到惊讶。

根据RFC 2616第4.3节“消息正文”：

服务器应读取并转发任何请求的消息体；如果请求方法不包括实体实体的定义语义，则在处理请求时应忽略消息体。

也就是说，服务器应该始终从网络中读取任何提供的请求体（检查内容长度或读取分块体等）。此外，代理应该转发他们收到的任何此类请求。然后，如果RFC为给定方法的主体定义了语义，那么服务器实际上可以使用请求主体来生成响应。然而，如果RFC没有定义主体的语义，那么服务器应该忽略它。

这与上面Fielding的引用一致。

第9.3节“GET”描述了GET方法的语义，没有提到请求体。因此，服务器应该忽略它在GET请求中收到的任何请求体。

根据XMLHttpRequest，它无效。根据标准：

4.5.6 send（）方法客户send（[正文=空]）启动请求。可选参数提供请求身体如果请求方法是GET或HEAD，则忽略该参数。如果任一状态都不是，则引发InvalidStateError异常打开或设置send（）标志。send（body）方法必须运行以下步骤：如果状态未打开，则引发InvalidStateError异常。如果设置了send（）标志，则引发InvalidStateError异常。如果请求方法是GET或HEAD，请将body设置为null。如果body为空，则转到下一步。

虽然，我认为这不应该，因为GET请求可能需要大量的正文内容。

因此，如果您依赖浏览器的XMLHttpRequest，它很可能无法工作。

例如，它适用于Curl、Apache和PHP。

PHP文件：

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

Console命令：

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

输出：

GET
{"the": "body"}

虽然您可以做到这一点，但只要HTTP规范没有明确排除它，我建议避免它，因为人们不希望事情以这种方式工作。HTTP请求链中有许多阶段，虽然它们“大部分”符合HTTP规范，但唯一可以保证的是，它们的行为将与web浏览器传统使用的一样。（我想的是透明代理、加速器、A/V工具包等）

这就是稳健性原则背后的精神。大致上，“接受的内容要自由，发送的内容要保守”，你不想在没有充分理由的情况下突破规范的界限。

然而，如果你有充分的理由，那就去做吧。

你可以用身体发送GET，也可以发送POST，然后放弃RESTish宗教信仰（这并不是很糟糕，5年前只有一个信仰的成员——他在上面的评论）。

这两个都不是很好的决定，但发送GET主体可能会防止某些客户端和某些服务器出现问题。

进行POST可能会遇到一些RESTish框架的障碍。

Julian Reschke在上文中建议使用非标准HTTP头，如“SEARCH”，这可能是一个很好的解决方案，只是它不太可能被支持。

列出能够和不能做到上述每一项的客户可能是最有成效的。

无法发送带有正文的GET的客户端（我知道）：

XmlHTTPRequest Fiddler

可以发送带有正文的GET的客户端：

大多数浏览器

可以从GET检索正文的服务器和库：

阿帕奇PHP文件

从GET中剥离主体的服务器（和代理）：

?