为微服务构建REST API时，需要做出一些关于响应的设计决策。 某些响应显然是微服务周围协议的产物–例如3xx代码之类的东西都与重定向和路由有关。

通常，您将尝试获取正确的2xx代码以取得成功。 如有疑问，将为200（确定），但对于打算创建数据的请求，请考虑201（已创建），对于将在以后处理的请求，请考虑202（已接受）。

在本文中，我想讨论用于错误的4xx和5xx响应。 我还要考虑您的服务是否将尝试容忍下游错误。 您希望软件变得越复杂，内部异常就越精确。

确切地说，我的意思是简单。

笨拙的异常处理策略最终将导致艰苦的工作来应对所有用例。

简化简化简化

此刻，每当我被要求对微服务中的异常和错误提出意见时，我都会回答相同的答案。

有两类错误的...它出了问题，或者你就错了。

你错了

客户端错误最容易检测，需要与响应代码一样精确的错误处理。 通常，404错误并不是真正的例外，就如同返回零结果一样。 对于其他错误，您基本上得到了：

• 安全违规，在处理请求之前应在适当的框架中进行检查
• 无效的请求-通常是畸形的身体

容易忘记，如果随机的Json解析异常发生在正确的层，则可以简单地将其归类为您错了。

一旦知道了要尝试证明的简单分类，就可以轻松地了解要做什么和要测试什么。

错了

这些错误分为两类：

• 我的算法无法解决这种情况-对不起
• 某些下游服务无法正常工作

在这两个中，后者可能有一些变体，其中需要对错误应用重试策略，以便在给我们之前再次提出请求，从而避免出现网络故障，或者避免与多个相关服务进行某种机会游戏，目前其中任何一个都可能会出现故障。

提示：如果要获得回应就像Yahtzee的游戏一样，则需要添加一些重试，并且这些重试应该在明确定义的可重试范围内， 但出错了。

如果您的重试策略错误，它将重试以下内容：

• 我的算法无法应付
• 该请求永远不会有效

当然，生活中的事物不可能是二进制的吗？

有两种类型的人。 有人认为一切都是二元选择，然后还有其他人……

从标题的二进制选择开始是一个很好的/强烈的起点。 然后在必要时将每个类别分为子类别，可以帮助您处理特定的细微差别。

到目前为止，这对我们有用。

您可以逐步建立。

有两种类型的人员：懂得如何逐步构建事物的人员，以及……我将在另一天告诉您另一种类型的人员。

翻译自: https://www.javacodegeeks.com/2020/03/it-broke-vs-youre-wrong.html