rest - 使用 HTTP 204 vs 200 vs 404 来安全地表示资源不存在

Question

在我的 REST API 中，我有一些资源的普通 CRUD 端点。
如果我做 GET /items/42并且没有这样的项目，正常的行为是返回 404 NOT FOUND .

然而，一种情况让我担心。在这种情况下，客户端需要检查资源(由 token 隐式标识)是否存在，如果不存在，则创建它。因此，客户端将尝试检索资源，如果出现 404收到客户端应用程序将显示创建项目所需的 UI，然后继续 POST使用新资源。从某种意义上说，这是一种特殊的资源，因为它的 ID 是从其他参数派生的，它甚至在创建之前就已经知道了。例如，考虑一个用户注册过程；客户会问“我存在吗？如果不存在 -> 注册我”。

我真正关心的是我是否需要担心“虚假”404 :s?考虑到服务器通常被 API 网关、反向代理等包围，是否有任何风险 404 NOT FOUND由于一些与 REST 服务器本身无关的临时错误，可能由周围的实体产生？如果是这样，它可能会诱使客户端相信该项目尚未创建，现在应该创建它。即使由此产生POST创建项目的请求将失败，因为该项目已经存在，这不是很好，因为用户可能无缘无故地输入了数据等。

这是一个需要考虑的问题还是过于偏执？我想如果客户不能信任 404要成为幂等的(当然，在创建资源之前)，还会出现许多其他问题。 API网关或类似设备是否会报告404的任何实际情况？在其自己的？

如果这是一个有效的场景，我是否需要一个“更安全”、更明确的响应，说明请求确实成功但未找到资源，例如以 200 OK 响应带有空的 JSON 正文或 {isRegistered: false} , 204 NO CONTENT ，或类似？这为其他奇怪的事情打开了大门 - 如果对不存在的资源的请求将以 200 响应。伴随着一个空的主体，该项目的创建可能是一个 PUT而不是 POST ， 等等？这似乎是一堆蠕虫......这一切都归结为“404 是否保证给定的资源不存在？”。

Answer 1

404 非常明确:未找到资源，它是 client error (4xx) .通常，服务器端错误 (5xx) 不会干扰并在此处创建虚假 404。

作为替代方案，如果要创建的资源以独特的方式链接到另一个资源，您可以使用 OPTIONS询问服务器是否已经存在。

例如 :

OPTIONS /visitors/7883930/user-account

=> Allow: POST,OPTIONS (不存在)
=> Allow: GET,OPTIONS (存在)

这里的关键是要有一个 URI，允许在不知道其 ID 的情况下访问资源。但这并不总是可能的。