Question

HTTP GET请求是否正常出现状态代码为204 - No Content的响应？就像，这对于HTTP GET应该完成的内容来说，这在语义上是否正确？我知道 HTTP POST请求 204 - No Content 好。对于GET请求，如果没有数据要发回，204状态代码是否合适？我应该使用404，还是仅仅坚持200以获得成功但是空洞的回应？

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

Answer 1

204无内容

服务器已完成请求但不需要返回   entity-body，可能想要返回更新的元信息。该   响应可能包括新的或更新的元信息形式   实体标题，如果存在，应该与...相关联   要求的变体。

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

404 Not Found，200 OK空身和204 No Content具有完全不同的含义，有时我们无法使用正确的状态代码，但弯曲规则，他们会回来咬你一天。因此，如果您可以使用正确的状态代码，请使用它！

我认为GET或POST的选择非常个人化，因为他们都会做这项工作，但我建议你保留POST而不是GET，原因有两个：

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

Answer 2

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

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

GET的目的是检索资源。因此，虽然允许，但是HTTP 204不是最佳选择，因为响应中预期内容IS。如果服务器无法提供所请求的资源，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响应。

Answer 3

我将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

Answer 4

使用204的POST / GET在第一眼看上去似乎很好并且也可以工作。

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

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

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

Answer 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可能不是一个好主意，因为响应应包含导航到其他状态的链接。

HTTP获取204无内容：这是正常的

5 个答案:

204无内容