错误还是错误？

Question

我需要在服务器上实现以下场景：

1. 用户在给定的时间内发送了太多的答案，例如，它不能在一小时内提交超过3个帖子。
2. 用户已经用相同的文本发送了答案，以防止垃圾邮件。

我的问题是，实现客户机/服务器通信的正确方式是什么？服务器应该返回某种错误，例如，429和409，还是返回代码200，然后返回冲突的详细信息？我和我的经理争辩说，错误应该被退回。他说，错误是我们预期不会发生的事情，但在这种情况下，我们完全可以预料到。

Answer 1

您的经理将意外错误与应用程序故意拒绝执行请求的操作混为一谈。他说的关于前者是正确的，而不是后者。

任何不是500的内容都是API向用户返回的有意消息，因此不是意外的错误。经理关于意外错误的陈述是正确的，但是他把有意识的拒绝贴上了错误的标签，好像它们是意外的。

这可能是一个语义问题。因为你的经理似乎认为“错误”指的是意想不到的失败，所以试着用他们自己的语言与他们沟通。不要把有意识的拒绝说成是“错误”，而是“消极的反应”或“拒绝的请求”。你可能会发现他们更愿意听你的话，一旦你使用的话，他们使用他们。

然而，我不能告诉你如何说服你的经理。我不知道他们为什么要采取这样的立场，也不知道有什么东西能改变他们目前的想法。

我会在这里做的是通过你的经理的例子，因为我怀疑你可以索性地把他带到你的目标。与…有关的东西：

告诉我，当我们返回200的时候，冲突的细节是什么样子的？ MAN，他们应该解释为什么发生了某种failed. DEV，这也应该表明发生了什么样的故障?是的，因为这给了请求者need. DEV的信息--这意味着我们需要一个可能发生的各种故障的列表，这样请求者就可以对特定类型的故障做出适当的响应，这就是encountered. MAN是的。

此时，您可以展示这正是构建HTTP状态代码的目的。返回的消息可以随意选择；但是附加到此消息的HTTP状态代码只是一种标准化的“失败类型”，它可以帮助请求者快速分类遇到哪种故障(是否有效？是我的错吗？是API的错吗？不允许我访问这个端点吗？)

我们列出了每个人都使用的代码列表，这样每个能够编写软件的人都不必学习每个API自己的自定义错误代码，因为以各自独特的方式表达相同类型的错误将是不必要的麻烦。

如果你的经理仍然不让步，可以试着向他们询问解决方案的信息。为什么任意的“失败代码”会比通用HTTP状态代码更好呢？如果您使用HTTP状态代码，会发生什么不同的情况？

听取经理的意见，理解他们的推理，尝试解释为什么您可以使用更加标准化的HTTP状态代码来实现相同的目标。

但我想重申，我不能保证你们的经理愿意听取你们的意见，或者他们甚至有自己选择的理由(他们可能是在模仿现有的知识，而不打算把这些知识放在显微镜下)。祝好运。

Answer 2

HTTP协议具有用于速率限制429的特定代码。

非协议错误应该返回500个原因，然后你的客户可以变成一个异常。

在这里，我会简单地默默地放下副本。

返回一个成功对象(封装了许多可能的结果)的问题是，每次调用API之后都必须有一个大的if块，该块试图计算出发生了什么。

使用代码处理非协议错误的问题是当您得到实际的协议错误时会发生什么。