为微服务构建REST API时，需要做出一些关于响应的设计决策。 某些响应显然是微服务周围协议的产物–例如3xx代码之类的东西都与重定向和路由有关。
通常，您将尝试获取正确的2xx代码以取得成功。 如有疑问，将为200（确定），但对于打算创建数据的请求，请考虑201（已创建），对于将在以后处理的请求，请考虑202（已接受）。
在本文中，我想讨论用于错误的4xx和5xx响应。 我还要考虑您的服务是否将尝试容忍下游错误。 您希望软件变得越复杂，内部异常就越精确。
确切地说，我的意思是简单。
笨拙的异常处理策略最终将导致艰苦的工作来应对所有用例。
简化简化简化
此刻，每当我被要求对微服务中的异常和错误提出意见时，我都会回答相同的答案。
有两类错误的...它出了问题，或者你就错了。
你错了
客户端错误最容易检测，需要与响应代码一样精确的错误处理。 通常，404错误并不是真正的例外，就如同返回零结果一样。 对于其他错误，您基本上得到了：
- 安全违规，在处理请求之前应在适当的框架中进行检查
- 无效的请求-通常是畸形的身体
容易忘记，如果随机的Json解析异常发生在正确的层，则可以简单地将其归类为您错了。
一旦知道了要尝试证明的简单分类，就可以轻松地了解要做什么和要测试什么。
错了
这些错误分为两类：
- 我的算法无法解决这种情况-对不起
- 某些下游服务无法正常工作
在这两个中，后者可能有一些变体，其中需要对错误应用重试策略，以便在给我们之前再次提出请求，从而避免出现网络故障，或者避免与多个相关服务进行某种机会游戏，目前其中任何一个都可能会出现故障。
提示：如果要获得回应就像Yahtzee的游戏一样，则需要添加一些重试，并且这些重试应该在明确定义的可重试范围内， 但出错了。
如果您的重试策略错误，它将重试以下内容：
- 我的算法无法应付
- 该请求永远不会有效
当然，生活中的事物不可能是二进制的吗？
有两种类型的人。 有人认为一切都是二元选择，然后还有其他人……
从标题的二进制选择开始是一个很好的/强烈的起点。 然后在必要时将每个类别分为子类别，可以帮助您处理特定的细微差别。
到目前为止，这对我们有用。
您可以逐步建立。
有两种类型的人员：懂得如何逐步构建事物的人员，以及……我将在另一天告诉您另一种类型的人员。
翻译自: https://www.javacodegeeks.com/2020/03/it-broke-vs-youre-wrong.html