HTTP Get with 204 No Content: 正常吗答案

【问题标题】：HTTP Get with 204 No Content: Is that normalHTTP Get with 204 No Content: 正常吗
【发布时间】：2012-09-30 05:45:48
【问题描述】：

HTTP GET 请求得到状态码204 - No Content 的响应是否正常？就像，关于 HTTP GET 应该完成什么，这在语义上是否正确？我知道204 - No Content 对于HTTP POST-Request 来说是好的。对于 GET 请求，如果没有数据要发回，204 状态码是否合适？我应该使用 404，还是坚持使用 200 才能成功但没有响应？

此问题的用例是我为 Google App Engine 编写的 Java 应用程序。我正在向 servlet 发送请求，但是要发送回客户端的数据将通过 Channel API 套接字而不是 HTTP 响应传输。目前，我的客户端在请求正文中发送一个没有内容的 POST，并在轮询 Channel API 套接字之前等待来自 servlet 的 204 响应。因为在请求正文中没有发送任何数据，所以我正在讨论发送 GET 而不是 POST 对我来说是否更有意义。

【问题讨论】：

有一篇关于204状态码的文章很不错，请通过以下链接找到它：blog.ploeh.dk/2013/04/30/…
相关帖子 - RESTful - What should a DELETE response body contain

标签： google-app-engine http get http-status-codes channel-api

【解决方案1】：

204 无内容

服务器已完成请求，但不需要返回实体主体，并且可能想要返回更新的元信息。这响应可能包括新的或更新的元信息，形式为 entity-headers，如果存在应该与请求的变体。

根据RFC part for the status code 204，在我看来，GET 请求是一个有效的选择。

404 Not Found, 200 OK with empty body 和 204 No Content 含义完全不同，有时我们不能使用正确的状态码，但改变规则，它们总有一天会回来咬你，或者稍后。因此，如果您可以使用正确的状态码，请使用它！

我认为 GET 或 POST 的选择非常个人化，因为它们都可以完成工作，但我建议您保留 POST 而不是 GET，原因有两个：

您希望另一部分（如果我理解正确的话是 servlet）执行一个操作，而不是从中检索一些数据。
默认情况下，如果 URL 中没有参数，则 GET 请求是可缓存的，而 POST 则不是。

【讨论】：

我不知道 GET 是可缓存的，而 POST 不是；很好的信息学习。谢谢。
@ecbrodie 不客气，您可以找到更多关于缓存 GET 和 POST 请求的信息here

【解决方案2】：

我将 GET/204 与 RESTful 集合一起使用，该集合是一个已知固定长度但有孔的位置数组。

GET /items
    200: ["a", "b", null]

GET /items/0
    200: "a"

GET /items/1
    200: "b"

GET /items/2
    204:

GET /items/3
    404: Not Found

【讨论】：

我只想说你的例子非常简洁。干得好。
如果不是位置数组而是字符串搜索，你会使用它吗？ /item/a /item/c
/item/c 在语义上是 NotFound，我想。

【解决方案3】：

您当前的 POST 与 HTTP 204 响应的组合很好。

RFC 不支持使用 POST 作为 GET 的通用替代品，因为每个都有自己特定的目的和语义。

GET 的目的是检索资源。因此，虽然允许，但 HTTP 204 不会是最佳选择，因为响应中预期有内容。如果服务器无法提供请求的资源，HTTP 404 Not Found 或 HTTP 410 Gone 将是更好的选择。

RFC 还特别指出 HTTP 204 作为对 PUT、POST 和 DELETE 的适当响应，但对于 GET 省略了它。

请参阅RFC for the semantics of GET。

还有其他响应代码也可以返回，表示没有内容，这比 HTTP 204 更合适。

例如，对于条件 GET，您可能会收到不包含正文内容的 HTTP 304 Not Modified 响应。

【讨论】：

【解决方案4】：

带有 204 的 POST/GET 乍一看似乎很好，并且也可以工作。

文档说， 2xx——此类状态码表示客户端请求的操作已成功接收、理解、接受和处理。然而 4xx -- 4xx 类状态码适用于客户端似乎出错的情况。

因为，请求已在服务器上成功接收、理解和处理。结果是找不到资源。所以，在这种情况下，这不是客户端的错误，或者客户端没有出错。

因此，这应该是 2xx 系列代码，而不是 4xx。在这种情况下发送 204（无内容）将比 404 或 410 响应更好。

【讨论】：

【解决方案5】：

返回 204 的 Http GET 非常好，返回 404 也是如此。

重要的是您定义 API 的设计标准/指南，以便所有端点一致地使用状态代码。

例如：

您可以指示如果集合为空，则返回资源集合的 GET 端点将返回 204。在这种情况下，如果 2019 年 4 月没有投诉，GET /complaints/year/2019/month/04 可能会返回 204。这不是客户端错误，因此我们返回成功状态码 (204)。 OTOH，如果投诉编号 12345 不存在，GET /complaints/12345 可能会返回 404。
如果您的 API 使用 HATEOAS，则 204 可能不是一个好主意，因为响应应该包含导航到其他状态的链接。

【讨论】：