接口 api，后端结构返回问题？

[Zach369]

最近跟 ios 接口联调，ios 说我的 api 接口返回格式不合理。想问问大家工作中是怎么处理的？

我的接口返回样子：

   {
     "data": [
       {
         "id": 28,
         "action": 2,
         "user": {
           "id": 1,
           "name": "zach",
           "avatar": ""
         },
         "topic": {
           "id": "279a11cf-4a21-4772-ba07-5e51b499252d",
           "title": "",
           "content": "我是蛋糕 我在躲猫猫"
         },
         "comment_id": 1,
         "created_at": 1565834869
       }
     ],
     "pagination": {
       "current_page": 1,
       "per_page": 10,
       "total": 1
     }
   }

ios 想要的数据结构：

  {
    "data": [
      {
        "id": 28,
        "action": 2,
        "user_id": 1,
        "user_name": "zach",
        "user_avatar": "",
        "topic_id": "279a11cf-4a21-4772-ba07-5e51b499252d",
        "topic_title": "xxx",
        "topic_content": "我是蛋糕",
        "comment_id": 1,
        "created_at": 1565834869
      }
    ],
    "pagination": {
      "current_page": 1,
      "per_page": 10,
      "total": 1
    }
}

两者之间的变化 就是 将 user 和 topic 对象打散成 key：value 的形式。 想问问广大的后端开发人员以及 ios，大家是怎么处理的那？使用那种返回形式？

[elone]

现在用 GraphQL ,结构上就是第一种。我个人是觉得比较清晰。

[ddbullfrog]

JSON:API

[qq73666]

iOS 合理,数组是有序的!!

[dongisking]

跟你遇到一摸一样的问题，我做了第一个，前端说嵌套太多不方便他丢在组件里，于是我又改成第二种。现在的前端真的爽啊，套数据就完事了

[yuejieee]

作为一个 iOS 开发，显然第一种合理，而且第一种的层级数也没有很多

[woscaizi]

支持 ios，他的更简洁明了。
PS 我是后端程序员。

[zhang5388137]

你的接口只有 ios 接吗, 没有 android 或者 web 接吗

[Zach369]

@zhang5388137 是有的，多端：h5 android ios ..... 我问 android 他们说随意。 怎么都行。 h5 我来写。。

[awanganddong]

公司比较规范的绝大多数是第一种结构。json 层次分明。
至于一把梭把所有数据返给前端这种。其实后端更加省力。

[slgz]

@Vegetable #14 “ XXX 你这几个接口能不能给我合并成一个？” 这个情况你们是咋处理的

[maemual]

支持后端，iOS 就是懒而已

[hauibojek]

都没啥问题吧，叫上安卓端的同事一起讨论统一下就行。

[zhang5388137]

@Zach369 个人认为, 多端情况下, 以后端为主, 这次这个可能好改, android 等等随意, 以后指不定还要改什么东西...

[GroupF]

不支持 ios

[superpeaser]

@slgz 我觉得你说的这种也要分情况，进一个页面一下子请求几个接口也不是太好，之前我们查询一个字段都要整成一个接口，这谁能受得了

[Macolor21]

多层嵌套会降低算法复杂度，当然这一点点的性能损失不对。对于一些大量数据的服务就比较敏感了。没有绝对的对错。

[snail404]

瞎猜：接口是 laravel orm json 返回结构 ， 当然是支持了

[simpler]

第二种难道 不是一起偷懒么

[GzhiYi]

支持后端，没必要再做一次字段处理吧？

[rychan]

各有好坏
第一种层次分明，结构很清晰
第二种只是用起来方便而已