应用错误收集

这是一个很好的问题，我将以我个人的经验作为具体示例来回答。在用于我的一个项目的API中，我允许上传Excel电子表格，该电子表格将得到处理，并将结果JSON存储在服务器上。

如果在将数据保存到磁盘时出错，那么我将以JSend“ error”以及相应的错误消息作为响应，因为应该已经可以保存数据。

另一方面，如果其中一行中的数据无效（可能是错误的数据类型或范围错误），那么我知道电子表格中确切的一行（或几行）是错误的。在这种情况下，“失败”响应是适当的，因为JSend响应的data属性将包含每个不可处理行的所有行的列表（行号和错误消息）。

在“错误”响应的情况下，我将没有这种能力，因为我将被限制为单个message属性。但是，有了“失败”响应，我有了data属性，可以在其中用细粒度的问题列表进行响应。

因此，尽管没有错误，但数据本身并不正确，用户应返回并查看其电子表格，并解决由data属性标识的问题。 “失败”响应。

从HTTP错误的角度进行思考，尽管这是一个有趣的练习，但并不总是会导致精确的映射（4xx =失败，5xx =错误）。它与您要传达给客户端的内容更多有关：某些本不应该发生的严重错误（“错误”），或者 server 工作正常，但是您的 data 完全不符合标准（“失败”）。

最后，是否还要使用HTTP错误完全取决于您。您总是可以用200回应，然后让JSend讲话。但这是一个稍微不同（且有些宗教性）的讨论。：-）

我希望有帮助。