我正在为我们的应用程序开发一个新的RESTful Web服务。

当对某些实体执行GET时,客户端可以请求实体的内容。如果他们想添加一些参数(例如排序列表),可以在查询字符串中添加这些参数。

或者,我希望人们能够在请求主体中指定这些参数。HTTP/1.1似乎并没有明确禁止这一点。这将允许他们指定更多信息,可能会更容易指定复杂的XML请求。

我的问题:

这完全是个好主意吗?HTTP客户端在GET请求中使用请求体时会遇到问题吗?

https://www.rfc-editor.org/rfc/rfc2616


当前回答

您有一个选项列表,这些选项比使用GET请求体要好得多。

假设每个类别都有类别和项目。两者都由id标识(在本例中为“catid”/“itemid”)。您希望按照特定“顺序”中的另一个参数“sortby”进行排序。您希望传递“sortby”和“order”的参数:

你可以:

使用查询字符串,例如。example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc对路径使用mod_rewrite(或类似):示例.com/category/{catid}/item/{itemid}/{sortby}/{order}使用随请求传递的单个HTTP标头使用其他方法(例如POST)检索资源。

所有这些都有其缺点,但都比使用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发送消息体,但存在足够的歧义,如果不是所有服务器都支持它,我不会感到惊讶。

哪个服务器会忽略它?–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.

您还可以从Bing、Apple等获得400个Bad Request,这些请求由AkamaiGhost提供。

因此,我不建议对主体实体使用GET请求。

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

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

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

这与上面Fielding的引用一致。

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

罗伊·菲尔丁(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请求上发送有效负载主体可能会导致一些现有实现拒绝该请求。

您试图实现的目标已经用一种更常见的方法完成了很长时间,这种方法不依赖于在GET中使用有效负载。

您可以简单地构建特定的搜索中介类型,或者如果您希望更具RESTful,可以使用类似OpenSearch的方法,并将请求POST到服务器指示的URI,例如/search。然后,服务器可以生成搜索结果或构建最终URI并使用303重定向。

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

也就是说,URI无论如何都是针对非ASCII的任何内容进行编码的,application/x-www-form-urlencoded和multipart/form数据也是如此。如果您打算支持ReSTful场景,我建议使用此格式,而不是创建另一种自定义json格式。