在这个场景中有两个 HTTP 微服务：
服务 1 调用服务 2，要求它验证客户端提供给它的令牌。
协议（“合同”）是服务 2 应回复 200 OK 和关于已验证用户的 JSON 内容。
在服务 1 中，如果它收到响应 200 OK，是否值得进一步验证响应？
例如，响应的 JSON 正文被解析为一个对象。检查该对象是否被正确实例化而不是设置为 null 是否有价值？或者是否应该将其留给集成测试？
【问题讨论】：
UserID。
标签： microservices defensive-programming
严格来说，200 仅表示请求已成功处理。从业务角度来看，这与呼叫的实际结果无关。
您实际上依赖于“如果用户未通过身份验证，我们将抛出异常或以其他方式使调用失败”的约定来验证用户身份。
根据惯例，您可能会遇到用户未经身份验证但呼叫仍被成功处理的情况。
从这个角度来看，让 service2 返回一个响应可能是值得的，然后可以询问该响应以关闭这个循环。
或者，您可以让客户端直接调用身份验证服务，检索令牌，然后将此令牌与任何其他请求一起呈现。这意味着 service1 不再需要知道调用者是否经过身份验证。
问题是是否每次在服务 1 中进行测试 收到回复
抱歉，我似乎有点误解了问题的精神。
我有点困惑 - 你是在问，如果被测系统是 service1，那么 service2 的任何响应也应该是该测试的一部分吗？
我会说你必须进行一些测试来证明 service2 响应询问逻辑是正确的，但这可以在单元测试级别完成。我认为您不需要为针对已部署服务实例运行的测试执行此操作，这本质上更多是关于边界而不是内部的服务行为。
【讨论】：
你的方法还不错！
某些 HTTP 状态代码是为格式错误的请求等情况保留的。但在您的情况下，您要求 Service2 返回令牌信息！如果该令牌存在，则您指定正确，Service2 必须返回200 OK。现在您只需要指定如果令牌不再有效或不存在（或将这两种情况视为相同......）会发生什么。如果您指定，Service2 必须返回 404 Not found，如果它不知道令牌或令牌已过期，那么（在大多数情况下）Service1 不需要再进一步！在几乎任何语言/环境中解析状态代码都很便宜，但是在成功和错误情况下强制反序列化内容的成本相比之下非常昂贵。身份验证需要快速 - 所以我会在这里获取状态码！
关键是，必须在某处指定此行为！ （我们追求的是大摇大摆的定义！）
【讨论】：