HTTP GET 请求有状态码响应是否正常204 - No Content？就像，关于 HTTP GET 应该完成什么，这在语义上是否正确？我知道 a对于HTTP POST-Request204 - No Content是可以的。对于 GET 请求，如果没有数据要发回，204 状态码是否合适？我应该使用 404，还是坚持使用 200 才能成功，但响应却空无一物？
这个问题的用例是我正在为 Google App Engine 编写的 Java 应用程序。我正在向 servlet 发送请求，但是要发送回客户端的数据将通过 Channel API 套接字而不是 HTTP 响应传输。目前，我的客户端在请求正文中发送一个没有内容的 POST，并在轮询 Channel API 套接字之前等待来自 servlet 的 204 响应。因为在请求正文中没有发送任何数据，所以我正在讨论发送 GET 而不是 POST 对我来说是否更有意义。
204 无内容
服务器已完成请求，但不需要返回实体主体，并且可能希望返回更新的元信息。响应可能包括实体头形式的新的或更新的元信息，如果存在，应该与请求的变体相关联。
根据状态代码 204 的 RFC 部分，在我看来，它是 GET 请求的有效选择。
A 404 Not Found，200 OK空的身体，204 No Content完全不同的意思，有时我们不能使用正确的状态码，而是违反规则，他们会在一天或更晚的时候回来咬你。因此，如果您可以使用正确的状态码，请使用它！
我认为 GET 或 POST 的选择非常个人化，因为它们都可以完成工作，但我建议您保留 POST 而不是 GET，原因有两个：
我将 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
您当前的 POST 与 HTTP 204 响应的组合很好。
RFC 不支持使用 POST 作为 GET 的通用替代品，因为每个都有自己的特定目的和语义。
GET 的目的是检索资源。因此，虽然允许，但 HTTP 204 不会是最佳选择，因为响应中预期有内容。如果服务器无法提供请求的资源，则HTTP 404 Not Found或HTTP 410 Gone将是更好的选择。
RFC 还专门调用 HTTP 204 作为对 PUT、POST 和 DELETE 的适当响应，但对 GET 省略了它。
有关 GET 的语义，请参阅RFC。
还有其他响应代码也可以返回，表示没有内容，这比 HTTP 204 更合适。
例如，对于条件 GET，您可能会收到不包含正文内容的HTTP 304 Not Modified响应。
乍一看，带有 204 的 POST/GET 似乎很好，并且也可以工作。
文档说，2xx - 此类状态代码表示客户端请求的操作已成功接收、理解、接受和处理。而 4xx —— 4xx 类状态码用于客户端似乎出错的情况。
因为，请求已在服务器上成功接收、理解和处理。结果是找不到资源。因此，在这种情况下，这不是客户端的错误，或者客户端没有错误。
因此，这应该是系列 2xx 代码而不是 4xx。在这种情况下发送 204（无内容）将比 404 或 410 响应更好。
返回 204 的 Http GET 非常好，返回 404 也是如此。
重要的是您为 API 定义设计标准/指南，以便所有端点一致地使用状态代码。
例如：
GET /complaints/year/2019/month/04，如果 2019 年 4 月没有投诉，可能会返回 204。这不是客户端错误，因此我们返回成功状态码 (204)。OTOH，GET /complaints/12345如果投诉号 12345 不存在，可能会返回 404。