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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1946 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近跟 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，大家是怎么处理的那？使用那种返回形式？

93 条回复 • 2019-09-04 18:31:13 +08:00

kison73

2019-08-30 10:02:53 +08:00

都可以，主要是沟通好就可以

tabris17

2019-08-30 10:03:18 +08:00

当然是有层级的更合理。iOS 只是懒而已

DevinL

2019-08-30 10:03:21 +08:00

做为一个后端，当然是支持你了- -

misaka19000

2019-08-30 10:03:50 +08:00

显然你的合理，iOS 估计是懒不想处理这么多层级

justfindu

2019-08-30 10:05:19 +08:00

当然支持你啊而且你的接口他们可以直接对 user 和 topic 创建相应的 model. 应该是更方便呀

zhuzhibin

2019-08-30 10:05:47 +08:00 via iPhone

例如你的 topic 那一层只有一个 id 就没必要分层其实直接外层返回 topic_id

whypool

2019-08-30 10:06:42 +08:00

层级太多会被打的

90d0n

2019-08-30 10:07:38 +08:00

谁嗓门大听谁的 (支持你的格式

mhycy

2019-08-30 10:07:46 +08:00

作为一个前后端都写的表示，iOS 的那个接口建议更不合理 (偷懒+1

MetalCore

2019-08-30 10:08:31 +08:00

第一个数据结构 java 常用，第二个数据结构 php 常用

qiayue

2019-08-30 10:09:57 +08:00

@MetalCore 不是吧

SpiderShrimp

2019-08-30 10:10:59 +08:00

嘻嘻，你的好。虽说都可以实现没错，但是将同个对象的字段抽出来放到一起，可以提高 json 的可读性。

otakustay

2019-08-30 10:11:27 +08:00

但是为什么你的 comment_id 不是 comment: {id: xxx}呢？

Vegetable

2019-08-30 10:12:27 +08:00

首先，这东西没有什么规则可讲，有的前端比较懒，特点就是
“ XXX 你这几个接口能不能给我合并成一个？”
“这个接口包了这么多层吗？”

你这个数据我看起来，两个设计都有自己的优点，我偏向后边的，不在单个对象中包含二级对象，使用前缀进行区分。第一个那个多层数据结构，不局限在前端，如果想映射成对象，第一个做法是只定义一个对象，有所有的字段，第二个是定义 3 个对象，分别是记录本身，User 对象和 Topic 对象再进行关联，太麻烦了。

tabris17

2019-08-30 10:12:43 +08:00

@SpiderShrimp json 是给程序用的，又不是给你读的，真要读转换成 yaml 格式呗

SpiderShrimp

2019-08-30 10:14:50 +08:00

@tabris17 是吗？你没对接过吗？后端制定 json，前端难道不用理解？不理解如何编码呢？

tabris17

2019-08-30 10:17:30 +08:00

@SpiderShrimp 把 json 转成 yaml 给他读呗，文档是文档，代码是代码

MarkOrca

2019-08-30 10:18:06 +08:00

让前端给出理由，然后写进文档，说到底是给前端用的，他要什么样的就什么样的呗。

SpiderShrimp

2019-08-30 10:21:26 +08:00

@tabris17 多此一举。后面的那个那么多 topic 前缀，倘若 topic 字段多了，看起来肯定没上面的舒服，但如果像前面 13#说的 comment_id 这种，字段只有一个，那就没必要抽成一个对象。

xrzxrzxrz

2019-08-30 10:23:46 +08:00

第一种分层结构比较清晰明了，好理解，比较面相对象，不过嵌套多层
第二种用起来方便，结构就没那么清晰了，也可以说是懒吧 0 0
不过我觉得其实各有利弊吧，毕竟开发方便些也算是一种优势吧。。（最后就看前端后端谁的态度强硬了）（手动狗头）

elone

2019-08-30 10:35:50 +08:00

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

ddbullfrog

2019-08-30 10:37:56 +08:00

JSON:API

qq73666

2019-08-30 10:38:28 +08:00

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

dongisking

2019-08-30 10:40:46 +08:00 via Android

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

yuejieee

2019-08-30 10:41:39 +08:00

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

woscaizi

2019-08-30 10:45:33 +08:00 via iPhone

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

zhang5388137

2019-08-30 10:48:10 +08:00

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

Zach369

2019-08-30 10:58:09 +08:00

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

awanganddong

2019-08-30 11:09:53 +08:00

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

slgz

2019-08-30 11:23:34 +08:00

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

maemual

2019-08-30 11:25:27 +08:00

支持后端，iOS 就是懒而已

hauibojek

2019-08-30 11:26:07 +08:00

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

zhang5388137

2019-08-30 11:26:56 +08:00

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

GroupF

2019-08-30 11:27:34 +08:00

不支持 ios

superpeaser

2019-08-30 11:40:41 +08:00

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

Macolor21

2019-08-30 11:50:35 +08:00 via iPhone

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

snail404

2019-08-30 11:58:09 +08:00

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

simpler

2019-08-30 12:00:59 +08:00

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

GzhiYi

2019-08-30 12:06:16 +08:00 via iPhone

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

rychan

2019-08-30 12:08:14 +08:00

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

yixiang

2019-08-30 12:21:04 +08:00

哪个好放在一边，没有必要听 ios 的意见。

既然后端接口是给多个端用的，那就不应该照顾单独一个端的开发，而是后端人员说了算。

假设安卓先开发完成，已上线，ios 说接口格式不合理，于是你改了格式，然后安卓端崩了，谁的锅？首先是团队总负责人（流程分工不清晰），其次是实际负责后端的后端人员，再次才是提出意见的 ios。

他不用为他的意见负责。但你写了接口是要给多端负责的。

a15819620038

2019-08-30 12:46:09 +08:00

理论上层级越少越好。

LeeSeoung

2019-08-30 12:46:17 +08:00

组件需要做成啥样就提供啥样的数据，哪分那么多好坏，你提供第一种，组件要求第二种的格式，你后端就算返回第一种，也还是需要前端去手动拼接，这种东西问清楚前因后果就行了。

sparkle2015

2019-08-30 13:28:53 +08:00

作为一个前端和 app 开发者，目前为止用过的是第一种，第二种还没见到过。第一种层次分明，意义明确，而且对于后端实现也更简单 (写过点 rails)，看个 GitHub 的 API 设计: https://developer.github.com/v3/repos/comments/#response。第二种无论是客户端还是后端的角度我个人都接受不了。

Vegetable

2019-08-30 13:32:49 +08:00

@slgz 看嗓门

Egfly

2019-08-30 13:40:19 +08:00

支持第一种，因为我就是这么处理的 ( :dog)。我们前端也能接受第一种，但是要能处理成第二种他们更乐意

fhvch

2019-08-30 13:49:20 +08:00

哥们，我觉得你给的数据没毛病~

Hyseen

2019-08-30 13:55:56 +08:00

作为一个后端，当然是支持第一种了

optional

2019-08-30 14:03:38 +08:00

当然是第一种，如果前端喜欢第二种让他自己处理

learnshare

2019-08-30 14:08:33 +08:00

你做得对，比较合理

encro

2019-08-30 14:14:30 +08:00

当然第一种，model 关联，接口数据就出来了，为什么还人工处理一层，浪费时间，容易出 BUG。
问题在于你们写的模型不一样，你可以搜索一个好点的客户端代码 JSON 解析器？

also24

2019-08-30 14:24:25 +08:00

如果 user topic 这两个结构，在其它接口中也有出现，且结构逻辑统一，我觉得第一种更好一些。

如果这只是一个单独的接口，我觉得两种都可以接受。
但是第二种对客户端来说，在反序列化的时候会更方便一些。

IamUNICODE

2019-08-30 14:30:10 +08:00

几年前我坚持第一个，因为我觉得这样分更合理，后来跟手机端对接久了，就第二个了。。。手机端水平不一样，遇到一个好的不容易，他们要什么就什么吧。。。

youxiachai

2019-08-30 14:37:29 +08:00

ios 解析 json 还是不方便....
不过也是 ios 赖....

Felldeadbird

2019-08-30 14:48:49 +08:00

我觉得第二个好。第一个层次清晰，但是呢浪费了自己时间啊。因为用你接口的人，有时候喜欢平级一次性输出所有东西，偷懒啊。

当然，具体看业务发展。如果后续需要更复杂的交互，必定第一种。

zifangsky

2019-08-30 14:56:50 +08:00

作为一个后端，当然是支持第一种了

oaix

2019-08-30 15:33:01 +08:00

嵌套的模型也可以返回展平的结构的。
@JsonUnwrapped 是你的好朋友

linxl

2019-08-30 15:38:58 +08:00

有个问题, 这里的 data 是指什么?

jjianwen68

2019-08-30 15:48:08 +08:00

个人倾向第一种，逻辑清晰

11ssss

2019-08-30 15:49:10 +08:00

做为一个后端，当然是支持你了

Airon

2019-08-30 15:49:19 +08:00

作为一个后端，方便的情况下会返回第二个。因为懒得和用户端开发扯皮。

varrily

2019-08-30 15:59:39 +08:00

graphql 是否能解决你们的争议？

0x000007

2019-08-30 16:15:38 +08:00

不出现这种我都能接受
```
{
"data": {
1: {
"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
}
}
```

Zach369

2019-08-30 16:27:12 +08:00

@0x000007 你的 markdown 没解析出来。没理解你的意思。为什么不能接受第一种那？