我正在为我们的应用程序开发一个新的RESTful Web服务。
当对某些实体执行GET时，客户端可以请求实体的内容。如果他们想添加一些参数（例如排序列表），可以在查询字符串中添加这些参数。
或者，我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这一点。这将允许他们指定更多信息，可能会更容易指定复杂的XML请求。
我的问题：
这完全是个好主意吗？HTTP客户端在GET请求中使用请求体时会遇到问题吗？
https://www.rfc-editor.org/rfc/rfc2616
当前回答
我向IETF HTTP工作组提出了这个问题。Roy Fielding（1998年，http://1.1文档的作者）的评论是
“…一个实现将被破坏，无法执行除解析和丢弃该主体之外的任何操作”
RFC 7213（HTTPbis）规定：
“GET请求消息中的有效负载没有定义的语义；”
现在看来很明显，其意图是禁止GET请求体上的语义，这意味着请求体不能用于影响结果。
如果你在GET上包含一个主体，那么有一些代理肯定会以各种方式破坏你的请求。
总之，不要这样做。
其他回答
得到，用身体！？
在规范方面，你可以，但是，这不是一个好主意，我们将看到这样做是不明智的。
RFC 7231§4.3.1规定身体“没有定义的语义”，但这并不是说它是被禁止的。如果你在请求中附加了一个主体，那么你的服务器/应用程序将从中得到什么，这取决于你。RFC继续声明GET可以是“各种数据库记录的编程视图”。显然，这样的视图多次由大量输入参数定制，这些参数放在请求目标的查询组件中并不总是方便甚至安全的。
好的：我喜欢冗长的辞藻。很明显，读取/获取资源不会对服务器产生任何可观察到的副作用（该方法是“安全的”），并且无论第一个请求的结果如何，都可以以相同的预期效果重复请求（该方法“幂等”）。
糟糕的是：HTTP/1.1的早期草案禁止GET具有主体，而且据称，某些实现直到今天都会丢弃主体、忽略主体或拒绝消息。例如，哑HTTP缓存可能只从请求目标构建缓存密钥，而忽略了主体的存在或内容。更愚蠢的服务器可能会如此无知，以至于将主体视为一个新的请求，这实际上被称为“请求走私”（这是将“请求发送到一个设备，而另一个设备不知道它”的行为-源）。
由于我认为主要关注的是实现之间的不可操作性，正在进行的工作建议将GET主体分类为“不应该”，“除非（请求）直接发送给一个源服务器，该服务器先前已在带内或带外表示此类请求有目的，并且将得到充分支持”（我的重点）。
解决方法：对于这种方法的一些问题，可以使用一些技巧。例如，不知道主体的缓存可以通过简单地将从主体派生的哈希附加到查询组件来间接地变得知道主体，或者通过响应缓存控制（没有来自服务器的缓存头）来完全禁用缓存。
唉，当涉及到请求链时，人们往往无法控制——甚至无法意识到所有当前和未来的HTTP中介以及它们将如何处理GET主体。这就是为什么这种方法通常被认为是不可靠的。
但是POST不是幂等的！
POST是一种替代方法。POST请求通常包括一个消息体（仅用于记录，正文不是要求，请参阅RFC 7230§3.3.2）。RFC 7231（§4.3.3）中的第一个用例示例是“向数据处理过程提供数据块[…]”。所以，就像GET与身体一样，身体在后端发生什么取决于你。
好处：当您希望出于任何目的发送请求体时，也许可以采用一种更常见的方法，这样可能会从您的团队成员中产生最少的噪音（有些人可能仍然错误地认为POST必须创建资源）。
此外，我们经常向其传递参数的是一个对不断变化的数据进行操作的搜索函数，只有在响应中提供明确的新鲜度信息时，POST响应才可缓存。
糟糕的是：POST请求没有被定义为幂等，导致请求重试犹豫。例如，在页面重新加载时，浏览器不愿意重新提交HTML表单，而不会向用户提示不可读取的隐藏消息。
解决方法：好吧，POST没有被定义为幂等并不意味着它不一定是幂等的。事实上，RFC 7230§6.3.1写道：“知道（通过设计或配置）对给定资源的POST请求是安全的用户代理可以自动重复该请求”。因此，除非您的客户端是HTML表单，否则这可能不是真正的问题。
QUERY是圣杯
有人提出了一种新的方法QUERY，它确实定义了消息体的语义，并将该方法定义为幂等。看看这个。
编辑：顺便说一句，我在发现了一个代码库后，无意中遇到了这个StackOverflow问题，在该代码库中，他们只将PUT请求用于服务器端搜索功能。这是他们的想法，包括一个带参数的体，并且也是幂等的。遗憾的是，PUT的问题在于请求体具有非常精确的语义。具体来说，PUT“请求创建目标资源的状态或将其替换为[正文]中的状态”（RFC 7231§4.3.4）。显然，这排除了PUT作为一个可行的选项。
我不建议这样做，这违背了标准做法，也没有提供那么多回报。您希望保留内容的正文，而不是选项。
罗伊·菲尔丁（Roy Fielding）关于在GET请求中包含身体的评论。
对换句话说，任何HTTP请求消息都允许包含消息体，因此必须考虑到这一点来解析消息。然而，GET的服务器语义受到限制，使得主体（如果有的话）对请求没有语义意义。解析的需求与方法语义的需求是分开的。所以，是的，你可以用GET发送一个身体，但不，这样做从来都没有用。这是HTTP/1.1分层设计的一部分，一旦规范被划分（正在进行中），分层设计将再次变得清晰。……罗伊
是的，您可以用GET发送请求体，但它应该没有任何意义。如果您通过在服务器上解析它并根据其内容更改响应来赋予其含义，那么您将忽略HTTP/1.1规范第4.3节中的建议：
…如果请求方法不包含实体体的定义语义，则在处理请求时应忽略消息体。
以及HTTP/1.1规范第9.3节中GET方法的描述：
GET方法意味着检索请求URI标识的任何信息（[…]）。
其声明请求主体不是GET请求中的资源标识的一部分，而是请求URI。
使现代化
被称为“HTTP/1.1规范”的RFC2616现在已经过时。2014年，它被RFC7230-7237取代。引号“处理请求时应忽略消息正文”已删除。现在只是“请求消息框架独立于方法语义，即使该方法没有定义消息体的任何用途”第二个引号“GET方法意味着检索任何信息……由请求URI标识”被删除。-来自评论
根据HTTP 1.1 2014规范：
GET请求消息中的有效负载没有定义的语义；在GET请求上发送有效负载主体可能会导致一些现有实现拒绝该请求。
我向IETF HTTP工作组提出了这个问题。Roy Fielding（1998年，http://1.1文档的作者）的评论是
“…一个实现将被破坏，无法执行除解析和丢弃该主体之外的任何操作”
RFC 7213（HTTPbis）规定：
“GET请求消息中的有效负载没有定义的语义；”
现在看来很明显，其意图是禁止GET请求体上的语义，这意味着请求体不能用于影响结果。
如果你在GET上包含一个主体，那么有一些代理肯定会以各种方式破坏你的请求。
总之，不要这样做。
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发送消息体，但存在足够的歧义，如果不是所有服务器都支持它，我不会感到惊讶。
