2

假设我们有一个 API，其路由/foo/<id>表示对象的实例，如下所示：

class Foo:
    bar: Optional[Bar]
    name: str
    ...

class Bar:
    ...

（Python 中的示例只是因为它方便，这是关于 HTTP 层而不是应用程序逻辑。）

我们想在 下暴露完整的序列化Foo实例（可能有许多其他属性）/foo/<id>，但是为了效率，我们也想暴露/foo/<id>/bar给我们给定的.bar属性Foo。

在这里时404用作状态响应对我来说感觉很奇怪，因为如果您请求一些任意不正确的路线（例如，），您会得到相同的状态代码；如果我们要在我们的客户端层自动处理 404 状态，那么可能会用“我们忘记登录”或“客户端 URL 路由错误”之类的解释来误解这一点。barNone/random/gibberish

但是，200使用响应体null（如果我们使用 JSON 进行序列化）也感觉很奇怪，因为在给定端点处实体的存在或不存在通常是通过状态而不是正文中的内联来传达的。204在这里说一个空的响应体是否正确？是404正确的方法，如果是这样，服务器传达细微差别的正确方法是什么，例如“但这是完全预期且正确的路线”或“实际上您指定的 foo-ID 不正确，这不是因为属性未设置而丢失”。

以不同方式表示该属性的缺失有哪些优点和缺点？

4

3 回答 3

1

的404，https ://developer.mozilla.com说，

In an API, this can also mean that the endpoint is valid but the resource itself does not exist.

所以我认为这是可以接受的。204在这种情况下并没有让我觉得特别古怪，但更常见的是（至少是 IME）与DELETEs 相关联（有时PUTs/ POSTs 不返回结果。）

于 2021-07-29T00:17:24.097 回答
1

我想知道您是否可以更清楚地阐明为什么200带有null响应主体的 a 是奇怪的。我认为它可以准确地传达您想要的内容，只要您不试图区分Foo没有bar（例如Foo.has_key?(bar)）和明确设置为的给Foo定。barnull

于 2021-07-29T00:55:40.877 回答
1

我也为此苦苦挣扎，因为：

  1. 404 可以指向不存在的 url，或者可以接受但特定引用资源不存在的路径。我还使用它在带有不存在标识符的请求正文上出错。

  2. 很多人将这些错误塞进错误的请求 (400) 错误代码中，这在某种程度上是可以接受的，但也是一种逃避。（从字面上看，服务器未成功处理的任何内容都可以归类为错误请求，如果您考虑一下）

  3. 考虑到 2（上），有时使用带有一些有用消息正文的 400 来消除没有完全提交 404 的内疚感，但这需要客户端的一些解析期望，这并不总是很好。还返回一个 400 ，根据这种情况，这是对客户端的一种刺激，因为 400 错误应该完全是客户端的错误，与请求的结构有关，而不是因为客户端要求的东西不在您的数据库中。

400 Bad Request 响应状态代码表示服务器不能或不会处理请求，因为某些东西被认为是客户端错误（例如，格式错误的请求语法、无效的请求消息帧或欺骗性请求路由）。

  1. 一般的感觉是 200 意味着一切都很好，因此总是默认响应将始终包含某种形式的主体，而不是 null。（对吗？？）我不鼓励在这些情况下使用 200。虽然 204 不承担必须携带响应正文的责任，但它们也传达了“某事有效”的信息，这不是您想在这里发送的信息，对吗？

我想说什么？周到的 API 设计很难。

于 2021-07-29T16:21:00.447 回答