带有请求正文的 HTTP GET

Roy Fielding's comment about including a body with a GET request。

是的。换句话说，任何 HTTP 请求消息都被允许包含消息体，因此必须考虑到这一点来解析消息。但是，GET 的服务器语义受到限制，因此主体（如果有）对请求没有语义意义。解析的要求与方法语义的要求是分开的。所以，是的，您可以使用 GET 发送正文，但不，这样做从来没有用处。这是 HTTP/1.1 分层设计的一部分，一旦规范被划分（正在进行中），它将再次变得清晰。 ....罗伊

是的，您可以使用 GET 发送请求正文，但它应该没有任何意义。如果您通过在服务器上解析它并根据其内容更改您的响应来赋予它意义，那么您将忽略 the HTTP/1.1 spec, section 4.3 中的此建议：

...如果请求方法不包括为实体主体定义的语义，则在处理请求时应该忽略消息主体。

以及 the HTTP/1.1 spec, section 9.3 中 GET 方法的描述：

GET 方法意味着检索由 Request-URI 标识的任何信息（[...]）。

它指出请求正文不是 GET 请求中资源标识的一部分，只是请求 URI。

更新

被称为“HTTP/1.1 规范”的 RFC2616 现已过时。 2014 年，它被 RFC 7230-7237 取代。引用“处理请求时应该忽略消息正文”已被删除。现在只是“请求消息框架独立于方法语义，即使该方法没有定义消息体的任何用途”第二个引用“GET 方法意味着检索任何信息……由 Request-URI 标识”被删除。 - 来自评论

从 HTTP 1.1 2014 Spec：

GET 请求消息中的有效负载没有定义的语义；在 GET 请求上发送有效负载正文可能会导致某些现有实现拒绝该请求。

---

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

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

但是，如果您有充分的理由，那就去吧。

---

如果您尝试利用缓存，您可能会遇到问题。代理不会在 GET 正文中查看参数是否对响应有影响。

---

restclient 和 REST console 都不支持，但 curl 支持。

HTTP specification 在第 4.3 节中说

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

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

Section 5.2 说

Internet 请求所标识的确切资源是通过检查 Request-URI 和 Host 标头字段来确定的。

Section 9.3 说

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

这共同表明，在处理 GET 请求时，服务器不需要检查 Request-URI 和 Host 标头字段以外的任何内容。

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

---

Elasticsearch 接受带有正文的 GET 请求。甚至似乎这是首选方式：Elasticsearch guide

一些客户端库（如 Ruby 驱动程序）可以在开发模式下将 cry 命令记录到标准输出，并且它广泛使用这种语法。

---

您可以发送带有正文的 GET 或发送 POST 并放弃 RESTish 宗教信仰（这还不错，5 年前只有一个信仰者——他的评论链接在上面）。

两者都不是很好的决定，但发送 GET 正文可能会阻止某些客户端和某些服务器出现问题。

做一个 POST 可能会遇到一些 RESTish 框架的障碍。

Julian Reschke 在上面建议使用像“SEARCH”这样的非标准 HTTP 标头，这可能是一个优雅的解决方案，但它更不可能被支持。

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

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

XmlHTTPRequest 提琴手

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

大多数浏览器

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

阿帕奇

PHP

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

?

---

您尝试实现的目标已经用一种更常见的方法完成了很长时间，并且不依赖于使用带有 GET 的有效负载。

您可以简单地构建您的特定搜索媒体类型，或者如果您想要更加 RESTful，请使用 OpenSearch 之类的东西，然后将请求发布到服务器指示的 URI，例如 /search。然后，服务器可以生成搜索结果或构建最终 URI 并使用 303 重定向。

这具有遵循传统 PRG 方法的优点，帮助缓存中介缓存结果等。

也就是说，对于任何非 ASCII 的内容，URI 都会被编码，application/x-www-form-urlencoded 和 multipart/form-data 也是如此。如果您打算支持 ReSTful 场景，我建议您使用它而不是创建另一种自定义 json 格式。

---

我向 IETF HTTP WG 提出了这个问题。 Roy Fielding（1998 年 http/1.1 文档的作者）的评论是：

“......除了解析和丢弃该主体（如果收到）之外，实现将被破坏以执行任何其他操作”

RFC 7213 (HTTPbis) 指出：

“GET 请求消息中的有效负载没有定义的语义；”

现在似乎很清楚，其意图是禁止 GET 请求正文上的语义含义，这意味着不能使用请求正文来影响结果。

如果您在 GET 中包含一个正文，那么一些代理肯定会以各种方式破坏您的请求。

所以总而言之，不要这样做。

---

GET，有身体！？

规范方面你可以，但是，不明智地这样做不是一个好主意，正如我们将看到的那样。

RFC 7231 §4.3.1 声明主体“没有定义的语义”，但这并不是说它是被禁止的。如果您将正文附加到请求中，那么您的服务器/应用程序从中得到什么取决于您。 RFC 继续声明 GET 可以是“各种数据库记录的编程视图”。显然，这样的视图多次被大量输入参数剪裁，这些输入参数放在request-target的查询组件中并不总是方便甚至安全的。

好处：我喜欢措辞。很明显，一个读取/获取资源而对服务器没有任何可观察到的副作用（该方法是“安全的”），并且无论第一个请求的结果如何，都可以以相同的预期效果重复请求（该方法是“幂等的”）。

坏处： HTTP/1.1 的早期草案禁止 GET 有正文，并且 - 据称 - 直到今天，某些实现甚至会丢弃正文、忽略正文或拒绝消息。例如，一个愚蠢的 HTTP 缓存可能只从请求目标中构造一个缓存键，而忽略了正文的存在或内容。一个甚至更笨的服务器可能是如此无知，以至于它将正文视为一个新请求，这实际上被称为“请求走私”（这是一种“在另一个设备不知道的情况下向一个设备发送请求”的行为 - { 1}）。

由于我认为主要是对实现之间的不可操作性的担忧，work in progress 建议将 GET 主体分类为“不应该”，“除非 [请求] 是直接向源服务器发出的之前已经表明，在带内或带外，这样的请求是有目的的，并且会得到充分的支持”（强调我的）。

修复：有一些技巧可以用来解决这种方法的一些问题。例如，body-unware 缓存可以通过将派生自 body 的 hash 附加到查询组件来间接成为 body-aware，或者通过响应服务器的 cache-control: no-cache 标头完全禁用缓存。

唉，当涉及到请求链时，人们通常无法控制甚至不知道所有当前和未来的 HTTP 中介以及它们将如何处理 GET 主体。这就是为什么这种方法通常被认为是不可靠的。

但是POST，不是幂等的！

POST 是另一种选择。 POST 请求通常包含消息正文（仅作记录，正文不是必需的，参见RFC 7230 §3.3.2）。 RFC 7231 (§4.3.3) 中的第一个用例示例是“向数据处理过程提供数据块 [...]”。因此，就像 GET 与 body 一样，后端的 body 会发生什么取决于您。

好处：当一个人希望发送请求正文时，可能是一种更常见的方法，无论出于何种目的，因此可能会从您的团队成员那里产生最少的噪音（有些人可能仍然错误地认为 POST 必须创建一个资源）。

此外，我们经常将参数传递给一个搜索函数，该函数对不断变化的数据进行操作，并且只有在响应中提供了明确的新鲜度信息时，POST 响应才可缓存。

坏处：POST请求没有定义为幂等的，导致请求重试犹豫。例如，在页面重新加载时，浏览器不愿意重新提交 HTML 表单，而不用不可读的神秘消息提示用户。

修复：好吧，仅仅因为 POST 没有被定义为幂等并不意味着它一定不是。实际上，RFC 7230 §6.3.1 写道：“知道（通过设计或配置）对给定资源的 POST 请求是安全的用户代理可以自动重复该请求”。因此，除非您的客户端是 HTML 表单，否则这可能不是真正的问题。

QUERY是圣杯

有一个新方法 QUERY 的提议，它确实定义了消息体的语义并且将该方法定义为幂等的。请参阅this。

编辑：作为旁注，我在发现一个代码库后偶然发现了这个 StackOverflow 问题，在该代码库中他们仅使用 PUT 请求来实现服务器端搜索功能。这是他们的想法，即包含一个带有参数的主体并且也是幂等的。唉，PUT 的问题在于请求正文具有非常精确的语义。具体来说，PUT“请求创建目标资源的状态或将其替换为[主体中] 的状态”（RFC 7231 §4.3.4）。显然，这排除了 PUT 作为一个可行的选择。

---

来自 RFC 2616, section 4.3，“消息正文”：

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

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

这与上面菲尔丁的引述一致。

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

---

哪个服务器会忽略它？ – fijiaaron 2012 年 8 月 30 日 21:27

例如，谷歌做得比忽略它更糟糕，它会认为这是一个错误！

用一个简单的 netcat 自己试试：

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

（1234内容后面是CR-LF，所以一共是6个字节）

你会得到：

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

您还会收到来自 AkamaiGhost 服务的 Bing、Apple 等的 400 Bad Request。

所以我不建议将 GET 请求与 body 实体一起使用。

---

根据 XMLHttpRequest，它是无效的。从 standard：

4.5.6 send() 方法客户端。 send([body = null]) 发起请求。可选参数提供请求正文。如果请求方法是 GET 或 HEAD，则忽略该参数。如果任一状态未打开或设置了 send() 标志，则引发 InvalidStateError 异常。 send(body) 方法必须运行以下步骤： 如果状态未打开，则抛出 InvalidStateError 异常。如果设置了 send() 标志，则抛出 InvalidStateError 异常。如果请求方法是 GET 或 HEAD，则将 body 设置为 null。如果 body 为空，则进行下一步。

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

所以，如果你依赖浏览器的 XMLHttpRequest，它很可能是行不通的。

---

如果您真的想将可缓存的 JSON/XML 正文发送到 Web 应用程序，则放置数据的唯一合理位置是使用 RFC4648: Base 64 Encoding with URL and Filename Safe Alphabet 编码的查询字符串。当然，您可以只对 JSON 进行 urlencode 并将其放入 URL 参数的值中，但 Base64 给出的结果较小。请记住，存在 URL 大小限制，请参阅 What is the maximum length of a URL in different browsers?。

您可能认为 Base64 的填充 = 字符可能对 URL 的参数值不利，但似乎并非如此 - 请参阅此讨论： http://mail.python.org/pipermail/python-bugs-list/2007-February/037195.html 。但是，您不应该放置没有参数名称的编码数据，因为带有填充的编码字符串将被解释为具有空值的参数键。我会使用 ?_b64=<encodeddata> 之类的东西。

---

我不建议这样做，它违反了标准做法，并且没有提供那么多回报。您希望将正文保留为内容，而不是选项。

---

您有一个选项列表，这些选项比使用带有 GET 的请求正文要好得多。

假设您有每个类别的类别和项目。两者都由 id 标识（在本示例中为“catid”/“itemid”）。您想根据特定“顺序”中的另一个参数“sortby”进行排序。您想为“sortby”和“order”传递参数：

你可以：

使用查询字符串，例如 example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc 对路径使用 mod_rewrite（或类似）：example.com/category/{catid}/item/{itemid} /{sortby}/{order} 使用随请求传递的单个 HTTP 标头 使用不同的方法（例如 POST）来检索资源。

都有其缺点，但比使用 GET 和 body 要好得多。

---

我很不高兴 REST 作为协议不支持 OOP，Get 方法就是证明。作为一种解决方案，您可以将 DTO 序列化为 JSON，然后创建查询字符串。在服务器端，您可以将查询字符串反序列化为 DTO。

看看：

ServiceStack 中基于消息的设计

使用 WCF 构建基于 RESTful 消息的 Web 服务

基于消息的方法可以帮助您解决 Get 方法限制。您将能够像请求正文一样发送任何 DTO

Nelibur web service framework provides functionality which you can use

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

---

不符合 base64 编码的标头怎么办？ “某些应用程序参数：sdfSD45fdg45/aS”

长度限制hm。你不能让你的 POST 处理区分含义吗？如果你想要像排序这样的简单参数，我不明白为什么这会是一个问题。我想你肯定担心。

---

恕我直言，您可以只在 URL 中发送 JSON 编码（即 encodeURIComponent），这样您就不会违反 HTTP 规范并将您的 JSON 发送到服务器。

---

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

PHP 文件：

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

控制台命令：

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

输出：

GET
{"the": "body"}

---

即使一个流行的工具使用这个，正如这个页面上经常引用的那样，我认为它仍然是一个非常糟糕的主意，它太奇特了，尽管规范没有禁止。

许多中间基础设施可能会拒绝此类请求。

例如，忘记在您的网站前使用一些可用的 CDN，例如 one：

如果查看器 GET 请求包含正文，CloudFront 会向查看器返回 HTTP 状态代码 403（禁止访问）。

是的，您的客户端库也可能不支持发出此类请求，如此 comment 中所述。

---

关于一个老问题的想法：

在正文上添加内容，在查询字符串上添加正文的哈希，因此缓存不会成为问题，您将能够在需要时发送大量数据:)

---

创建一个 Requestfactory 类

import java.net.URI;

import javax.annotation.PostConstruct;

import org.apache.http.client.methods.HttpEntityEnclosingRequestBase;
import org.apache.http.client.methods.HttpUriRequest;
import org.springframework.http.HttpMethod;
import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
import org.springframework.stereotype.Component;
import org.springframework.web.client.RestTemplate;

@Component
public class RequestFactory {
    private RestTemplate restTemplate = new RestTemplate();

    @PostConstruct
    public void init() {
        this.restTemplate.setRequestFactory(new HttpComponentsClientHttpRequestWithBodyFactory());
    }

    private static final class HttpComponentsClientHttpRequestWithBodyFactory extends HttpComponentsClientHttpRequestFactory {
        @Override
        protected HttpUriRequest createHttpUriRequest(HttpMethod httpMethod, URI uri) {
            if (httpMethod == HttpMethod.GET) {
                return new HttpGetRequestWithEntity(uri);
            }
            return super.createHttpUriRequest(httpMethod, uri);
        }
    }

    private static final class HttpGetRequestWithEntity extends HttpEntityEnclosingRequestBase {
        public HttpGetRequestWithEntity(final URI uri) {
            super.setURI(uri);
        }

        @Override
        public String getMethod() {
            return HttpMethod.GET.name();
        }
    }

    public RestTemplate getRestTemplate() {
        return restTemplate;
    }
}

和@Autowired 在您需要和使用的任何地方，这是一个带有 RequestBody 的示例代码 GET 请求

 @RestController
 @RequestMapping("/v1/API")
public class APIServiceController {
    
    @Autowired
    private RequestFactory requestFactory;
    

    @RequestMapping(method = RequestMethod.GET, path = "/getData")
    public ResponseEntity<APIResponse> getLicenses(@RequestBody APIRequest2 APIRequest){
        APIResponse response = new APIResponse();
        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_JSON);
        Gson gson = new Gson();
        try {
            StringBuilder createPartUrl = new StringBuilder(PART_URL).append(PART_URL2);
            
            HttpEntity<String> entity = new HttpEntity<String>(gson.toJson(APIRequest),headers);
            ResponseEntity<APIResponse> storeViewResponse = requestFactory.getRestTemplate().exchange(createPartUrl.toString(), HttpMethod.GET, entity, APIResponse.class); //.getForObject(createLicenseUrl.toString(), APIResponse.class, entity);
    
            if(storeViewResponse.hasBody()) {
                response = storeViewResponse.getBody();
            }
            return new ResponseEntity<APIResponse>(response, HttpStatus.OK);
        }catch (Exception e) {
            e.printStackTrace();
            return new ResponseEntity<APIResponse>(response, HttpStatus.INTERNAL_SERVER_ERROR);
        }
        
    }
}

---