如何优雅的标准化处理接口返回数据结构

最近一直在为第三方开发团队写接口,因为第三方团队在外地开发,所以交流基本都是靠 Teambition 和 Email 来进行沟通的,写完接口都会更新在线文档给第三方人员使用。

但,参与写接口的人员比较多,虽然有编码规约,但中间还是出现了一个小问题,正常所有的接口返回的数据结构应该都是一致的,分为公共响应数据和业务响应数据 ,示例:

{
    "code": "108",
    "msg": "Service Currently Unavailable",
    "sign": "ERITJKEIJKJHKKKKKKKHJEREEEEEEEEEEE",
    "user_name": "24K大白羊",
    "email": "haoliang@outlook.jp"
}
  • code, msg, sign 三个参数为公共响应数据,任何接口响应数据中都必须包含着3个参数,且名称也要一模一样
  • 前端在接收接口返回数据时,优先判断签名是否正确
  • 次优先判断 code 的值是否为 100,如数值不等于 100 则表示有错误信息
  • user_name, email 为业务响应数据,上面 2 个判断都通过后,各接口根据实际业务显示对应的值

为了更好的操控这个结构,后面做了下面的改变,这样理论上各业务模块只需要关注 data_response 里的数据就可以了。

{
    "code": "20000",
    "msg": "Service Currently Unavailable",
    "sign": "ERITJKEIJKJHKKKKKKKHJEREEEEEEEEEEE",
    "data_response": {
        "user_name": "24K大白羊",
        "email": "haoliang@outlook.jp"
    }
}

在 Laravel 中如何优雅的处理公共响应数据呢,所有的人只关注具体的值就可以,不需要重复定义上面的数据结构。也不会出现我用 msg 存错误信息,而有的人用 message 来存错误信息,其他小伙伴儿是如何处理的呢?

api
《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
讨论数量: 7

可以用后置中间件控制输出内容

4年前 评论
SonyXbox 4年前
qingdiao (作者) 4年前

推荐使用trait封装一个固定结构,每次调用。

4年前 评论
24K大白羊 (楼主) 4年前

1.约定俗成
2.后置中间件
3.trait统一封装
4.dingo

4年前 评论
jaak

请求成功的数据用api资源就行,400 401 500这种出错直接抛出异常, 做一个全局的错误异常捕获处理返回,个人觉得dingo 有些偏重

4年前 评论

详见: https://cloud.google.com/apis/design/
正确返回{data: {}},错误配合4xx,5xx并返回{error:{}}

4年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!