我有一个这样的终结点：
GET /api/customer/primary
如果存在主要客户，我会返回
{
name: "customerName"
}
但是，如果我发送GET而主要客户不存在怎么办？
最好发送带有空JSON {}的200 OK
还是最好只发送204无内容？
答案 0 :(得分：1)
404是对此合适的状态代码。您试图将“主要客户”表示为资源，但在某些情况下这种关系不存在。这种情况非常清楚，对于GET请求，应该为404。
这是一种完全可以接受的交流方式。 404可能会通知客户端该资源尚不存在，并且可能可以使用PUT创建该资源。
204 No Content具有特定含义，对您的情况没有多大意义。 204不仅意味着没有响应主体（Content-Length: 0可以做到这一点），而且对于超媒体应用程序来说，它还有一个更具体的应用程序。具体来说，它表示当用户执行导致204的操作时，视图不应刷新。例如，这对于“更新”操作是有意义的，在该操作中，用户在处理文档时可以偶尔保存其进度。与205 Reset Content相反，它表示应重置“视图”，以便（也许）可以从头开始创建新文档。
大多数应用程序都不会走得太远。坦白说，我还没有看到一个。鉴于此，用200或Content-Length: 0返回204 No Content是几乎完全不相关的讨论。 HTTP规范当然不会禁止200 OK与Content-Length: 0一起使用。
有点切线。总而言之，404表示此“事物”不存在，在这里很合适。没有多种解释。有的人写了规范，有的人读得很好，在讨论的另一边则是错的人。
答案 1 :(得分：0)
但是，如果我发送GET而主要客户不存在怎么办？
最好发送带有空JSON {}的200 OK
还是最好只发送204无内容？
如果我正确地解释了您的问题，那么您并不是真正在询问状态代码，而是要使用哪种 schema 来管理API中的不同情况。
>对于像REST这样的情况，对话的两端不一定由相同的组织和相同的发布周期控制，您可能需要考虑到对话的一侧使用的是较新的架构版本。
那怎么可能呢？我见过的最好的处理方法集中在为扩展设计方案上-新字段是可选的，并且具有文档化的语义来说明如果缺少字段则应如何理解它们。
从这个角度看
{}
看起来不像是缺少的对象的表示形式-看起来像是具有所有可选字段默认值的对象的表示形式。
您可能想要的是类似Maybe或Option的东西-在这里，您承诺发回零个或一个对象的集合，而不是承诺不发回一个对象。我通常希望集合在JSON中表示为array，而不是object。
[]
现在，有了 that 的想法，我认为决定返回Maybe的表示形式是合理的，其中None的表示形式为零字节长，Some(object)的表示形式就是对象的JSON表示形式。
因此，在该设计204中，返回None很有道理，并且您可以保证，如果成功的响应返回一个主体，则确实存在某些东西。
这里需要权衡取舍-列表形式允许使用者始终解析数据，但是即使发送None，他们也必须这样做。另一方面，将空表示形式用于None可以节省解析，但要求使用者注意内容的长度。
因此，回顾您的两个建议，我希望使用204将是更成功的长期方法。
另一种可能性是，当您要表达没有可用对象时，将返回null基本类型。这将带有200响应，因为内容长度为4个字节。
null
答案 2 :(得分：-1)
HTTP 404状态的文本（“未找到”）是最接近这种情况的，但是：
状态码的第一位数字定义响应的类别。的 后两位数字没有任何分类作用。有5个 第一位数字的值：
1xx：信息性-收到请求，正在继续处理
2xx：成功-操作已成功接收， 理解并接受
3xx：重定向-必须采取进一步的措施才能 完成请求
4xx：客户端错误-请求包含错误的语法或无法 满足
5xx：服务器错误-服务器显然无法完成 有效请求
4xx被识别为错误，并且某些警报可能来自网络/安全性/日志记录基础架构204语义表示服务器已成功满足请求，并且没有其他要发送的内容-不完全是正在发生的事情。
因此，我建议使用以下任一方法：
200（带有空对象/数组）像您建议的那样。
200返回null object，例如： "none"（有效JSON）
或
{
"name": "NO_PRIMARY_CUSTOMER"
}
（这种空对象的实现取决于返回数据的特定系统行为）
2xx代码，结果为空不太常见但仍然可行的替代方法是返回2xx范围内的自定义HTTP代码（例如HTTP 230），结果为空。
使用此选项时应格外小心，如果API暴露给可能使用未知工具访问/监视API的广泛受众，则应避免使用该选项。