GET、PUT、DELETE 方法上的 404 与 204

如果请求想要获取/删除/更新不存在的资源，您希望返回什么？ 204 还是 404？

示例：api/blog/{id} 可以接受这些请求：GET、DELETE、PUT 和 api/blog 可以接受 GET 和 POST。

GET: api/blog 返回博客列表，GET: api/blog/{id} 返回单个博客，PUT: api/blog/{id} 更新单个博客，DELETE: api/blog/{id} 删除单个博客。

当给定标识符的资源为空时，我更喜欢使用 204，例如 api/blog/{id}，有时是 404。您有什么看法？为什么？

在我看来，重要的区别在于请求是否成功结束。

所以通常在大多数情况下 404 是可行的方法。

我建议这样做，因为 HTTP 响应代码是按结果分组的。 source

信息响应（100–199）
成功响应 (200–299)
重定向 (300–399)
客户端错误 (400–499)
服务器错误 (500–599)

例如流程可以是这样的：

在 204 上再次引用了 from MDN：

HTTP 204 No Content 成功状态响应代码表明请求已成功，但客户端不需要导航离开当前页面。

这可能会用于，例如，在实现“保存并继续 wiki 站点的编辑”功能。在本例中为 PUT 请求将用于保存页面，并且 204 No Content 响应将被发送以表明编辑不应被某些人取代其他页面。

如果请求想要获取/删除/更新不存在的资源，您希望返回什么？ 204 还是 404？

“这取决于。”

如果响应中的负载是“包含对错误情况的解释的表示，以及它是临时情况还是永久情况”，那么我将使用 4xx Client Error 状态代码。如果我想引起对请求的目标 uri 的注意，那么我将使用 404 Not Found。

另一方面，如果响应中的负载是资源的表示，或者成功操作的状态的表示，那么我将使用一些 2xx Successful 状态代码，通常是 { {3}}。

特别是，如果有效负载的长度为零字节，我通常会将 200 与 Content-Length: 0 一起使用，而不是 200 OK。 204 No Content 我保留那些我真的希望用户代理保持相同视图的情况。另见204。

（这里是课程的一部分 - 不要试图从随附的原因短语中猜测状态代码的含义。阅读定义。）

资源在任何给定时间是否具有“当前表示”是一个“资源设计”问题。尽管我们以前从未讨论过，但可以说该文档具有代表性。也许该表示的长度为零字节，也许它有一些默认表示，例如带有一堆空白的政府表格，稍后需要填写。

例如，某个时间段内的活动报告可能具有当前表示，即使报告中描述的时间段是未来。

205 Reset Content 响应 PUT 或 DELETE 是奇怪的。

PUT 在语义上接近 UPSERT，当我要求你用负载中提供的表示替换它时，你无法找到资源的当前表示，这很奇怪。

同样，DELETE 是将资源与其实现解耦。既然已经做了，为什么还要报告做不到呢？