请教大佬，一个微服务 API 返回数据合理性问题

可以研究一下缓存穿透，看看别人是怎么做的

需要根据调用方对错误感知程度的要求服务提供方对异常数据的敏感度来衡量返回数据的使用。

一般来说查询是可以容许空或无的情况，但如果是写或者业务严谨性要求高的服务（如订单处理）可能需要返回错误提示，更快的发现问题定位问题。

根据 HTTP 状态码(HTTP Status Code)
正确 id 并有数据就返回 200
id 不能为空= 601
找不到指定数据 = 602
等等
接收方只需要全局拦截 Status Code 就行，200 放行，其他状态码，直接拦截并输出提示语，提示语可以 api 返回也可以接收方自定义

双方只需要约定好状态码就行

传入的 ID 为空，属于客户端错误， 应该返回 HTTP 状态码 400
如果传入的 ID 无数据， 在 Get 模式下， 返加 HTTP 状态码 404 比较合理
在 Post 模式下， 返回空数据集比较合理

数据没找到建议报错
id 没传更报错（这是数据校验问题了）
另外严重不建议使用自定义 http status 的方式表示错误，遇到对这个敏感的库（比如 RestTemplate ）自定义开发量可能太大
设计 API 的同时设计客户端，API 别不好写，客户端别不好用，再适当考虑加一些 header 做 requestId ，错误编码，就差不多了

作为一个微服务高手，我可以教你怎么设计才是好的，最好的微服务是无感的，那就是你不知道你调用的是微服务接口还是本地的方法，你要朝着这个方向出发。

所以本地方法怎么设计，那么微服务就是怎么设计，本地方法如果需要校验参数，那么你也要校验参数，本地方法可以不校验参数，交给上游调用者来保证参数的正确性也可以。本地方法报错了，那么会抛出异常，同理微服务也可以做到的可以拦截 feign 的异常接口做处理，这样服务调用者同样也可以进行异常捕获，非常的舒服。这样设计的好处，就是任何时候都可以把模块代码 都可以拆成微服务被调用。

其实本地调用和远程调用就是调用方式不一样，一定要记住-仅仅是调用方式不一样，其他开发都一样。你一定要设计基本的框架，来做到无感。团队内部需要把微服务的接作为好定义，暴露参数和异常的情况。

如果你接入其他的部门的服务，那么就不要把他们当做微服务，而是外部接口作为调用，不能污染自己的服务模型。

我以前设计的微服务架构，可以随意的合并或者拆分，也就是多个微服务仅仅通过 maven 的构建参数，就可以合并一起成为一个整体服务进行部署，也可以随时拆分成多个微服务进行部署，这样的好处就是，如果是个人开发，那么就可以做到前期单体部署，后期可以慢慢的拆开，微服务部署

获取单条数据，发现不存在可以直接报错，用特殊的错误码。如果是 http 的直接 404 ，私有协议可以自定义一个错误码，交给上游决定如何处理。