对私有RESTAPI的调用返回400或500是否重要？

我们有一个私有的RESTAPI，它被锁定，只有我们控制的软件才能调用，而不是公众。许多端点采用JSON负载。如果反序列化JSON负载失败（例如负载具有

int

，其中预期为

Guid

），将引发异常，API将返回500内部服务器错误。从技术上讲，在这种情况下，它应该返回400个错误请求

如果不知道在这种情况下需要付出多少努力才能确保返回400，那么更改API以返回400是否有好处？调用软件和QA是唯一看到此错误的实体，并且仅当软件发送的数据与预期模型不匹配时才会发生此错误，这是一个关键缺陷。我认为这是额外的努力和维护，毫无收获

---

从REST的角度来看，400和500之间的区别会有很大帮助吗？

：

如果希望遵循严格的REST原则，则应返回4xx，因为问题在于发送的数据而不是服务器程序

为服务器错误保留5xx。例如，如果服务器由于站点中断或软件缺陷而无法执行该方法。5xx范围状态代码不应用于验证或逻辑错误处理

从技术角度来看：

如果明天其他程序员/团队将处理此问题，则报告的错误不会传递有用的信息

如果明天你必须将你的错误记录在一个中央错误日志中，你将污染它，它将产生错误的状态代码

因此，如果QA决定对错误运行报告/度量，那么它们将是错误的

你可能会增加你的技术债务，这可能会影响你未来的生产力 如果您使用JIRA之类的工具，您至少可以记录此问题或创建一个票证

对私有RESTAPI的调用返回400或500是否重要

一点点

元数据是：

status code元素是一个3位整数代码，描述服务器试图理解和满足客户机相应请求的结果。响应消息的其余部分将根据为该状态代码定义的语义进行解释

因为我们有大量的状态代码，通用客户机可以使用这些元数据来理解响应的广泛含义，并采取明智的行动

4xx和5xx之间的主要区别是问题的一般方向。指示请求中存在问题，并暗示客户端存在问题

状态代码的4xx（客户端错误）类表示客户端似乎已出错

表示服务器上有问题

5xx（服务器错误）类别的状态代码表示服务器意识到自己出错或无法执行请求的方法

所以，想象一下，如果您愿意的话，一个通用的反向代理充当负载平衡器。代理如何利用区分4xx和5xx的能力

嗯。。。5xx表示查询本身可能没有问题。因此，代理可以尝试将请求路由到集群中的另一个正常实例，以查看是否有更好的响应可用。它可以查看来自集群特定成员的5xx响应模式，并判断该实例是否健康。然后，它可以驱逐那个不健康的实例并提供一个替换

另一方面，对于4xx状态代码，这些缓解措施都没有任何意义——相反，我们知道问题出在客户端，将请求转发到另一个实例不会使事情变得更好

即使您不打算自动缓解服务器错误，区分这两个错误代码对于内部警报和报告仍然很有用

---

（在我维护的系统中，我们使用通用监控来区分4xx和5xx响应，并使用不同的阈值来确定是否应该呼叫我。正如您可能想象的那样，我投入了相当多的精力来优化该系统。）

对其投了赞成票。我认为错误代码的日志记录很重要，监视API上的500个错误以及内部错误也很好。问题中没有提到代理或负载平衡器等复杂问题。有了这种方法，在任何可能的情况下，我们都可以想象如果陨石撞击数据中心该怎么办。IMHO，在这里询问这种改变的好处，而不是QA和使用API实现调用软件的人，这是非常奇怪的。使用API的人可以获得更精确的好处信息。此外，有人可能期望得到500而不是400。在没有通知和讨论的情况下改变这一点可能会破坏某人已经在运行的解决方案。