你们在开发Api的时候有将Laravel进行统一Api响应格式吗？

之前写过一个

github.com/guanguans/laravel-api-r...

博客：laravel-api-response - 规范化和标准化 Laravel API 响应数据结构

在过去的经历中，也基本是以 code/msg/data 这三种结构，对于部分情况，比如没有权限、需要登录这些场景，应该算是返回不同 code 的最常见场景，当然，你也可以根据 HTTP Status Code 来检查。

其次，定义 code 的主要目的在于一些场景下，光靠返回错误信息可能不足以引导用户在前端做出一些操作，可以让前端根据不同的 code 来做一些事情，比如，显示引导、弹窗等等。

因为 msg 还要考虑国际化，所以用 code 来判断显然是更好的一种方案。

其次就是 msg，实际上，大部分时候可能都用不上，用得上的反倒是当出现错误的时候，返回一些错误信息，所以可以看到一些 api 设计中，其实是使用 erron/errors 之类的，而不是 msg，因为成功的 msg 没有太大的意义，前端也可以自己做成功的反馈，不依赖后端，而错误信息则要依赖后端了。

而在一些 API 的设计中，甚至都没有 code/msg，而是使用 success 来进行判断，或者直接判断 errors。

data 的争议其实比前两者还要大，像在 axios，如果使用 laravel 默认的分页结构，再加上这个 data ，前端需要访问数据时，就要用 resp.data.data.data 才能访问到，有一些抽象了，即便是封装过的，也要访问两层 data。

在一些设计中， 就主张将 data 放在根节点，meta 这些也提取出去，就像 jsonapi 规范这样，laravel 的 Resource 就偏向于这种，当然，你也可以自行定制。

之前在项目中有用到过 Laravel Resource，我个人觉得不是很好用，现在在用 spatie/laravel-data + code/msg/data/errors 的方式（目前 errors 设计的有些问题，之前做的是直接把 validator 的结果填充到 errors 的）。

控制器直接返回 Resource 或者 Data 愿景是好的，但是在之前的使用中，还是觉得不太合适。

需要前端特别处理的，或者特别常用的才会定义code，否则都会固定的code，前端只需要把msg的警告内容弹出来就可以了。我一般用这个包：github.com/jiannei/laravel-respons...

我们是 statu_code + data +message

你们讲的这个CODE我是明白 但是laavel要统一这个格式还挺麻烦的，比如说表单验证的错误信息异常你要自己拦截 分页信息用ResourceCollection后格式不是code message data这种，要自己再次包装很麻烦，除非你不用ResourceCollection格式化Api数据

那部分自己控制器调用$this->succcess这种来响应的话是可以统一，但是前端就的处理多种模式了