这是一个创建于 3053 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近公司开发一个 Web 新项目，就两个开发，一个前端加上我后端 PHP 开发，前端要求前后端分离，我只负责提供 api ，这倒是无所谓，但是他所有的请求都要求是 JSON 格式，我就有点受不了了。我倒是无所谓 JSON 还是 XML ，关键是一大段的 JSON ，嵌套 3 ， 4 层，包含各种数组，布尔值发送过来，这叫我后端怎么做验证？我之前是提议直接 K/V 形式， JSON 的话至少不要嵌套这么多，他说数据量太多， JSON 方便，嵌套是为了更好地组织结构，不然干嘛传 JSON 。
卧槽，各位大神怎么看？
第 1 条附言 · 2016-07-21 21:26:13 +08:00
哈哈，没想到会有这么多评论，还真是受教了。
对于设计 api ，我个人也有个不成熟的观点：
对外：
标准很重要，基本会采用 JSON 或 XML 来处理，对于 request 会尽量将其压平
对内：
在满足需求的前提下尽量设计得简单，因为我坚信代码越简单， bug 越少。所以我
基本上使用 k/V 形式，这样也能够充分使用框架的特性，有特殊需求如标签等需要传数组，
如果是 web 表单提交，直接加 key 后面加[]
提交，如果是 ajax 等，将数组序列化成字符串，挂载到指定 key 下，这样既简单也不失灵活性。
如果是移动端 api ， response 返回的 json 我也会尽量将其压平，因为 JAVA 是静态语言，嵌套太多，
java 需要构造很多的数据对象，非常麻烦。
这是我两年多开发来自己的一些总结，仅代表我个人的观点。
我吐槽其实也不仅仅是技术上的问题，就像评论说的带有自己的一些偏见，
因为前端年纪比我小，开发很激进，觉得自己会一点 angular.js, vue.js 就像是
走在了科技的前沿，说国内使用的技术，国外早就已经淘汰了。太过理想化，很多
细节又缺乏考虑，好几次出 bug 调试了半天，发现是路径写错了。
对待产品像是自己的试验场。活脱脱一个当年的自己，这也是我不愿争执的
一个最大的原因。
也非常感谢各位的指教与批评
对于设计 api ，我个人也有个不成熟的观点：
对外：
标准很重要，基本会采用 JSON 或 XML 来处理，对于 request 会尽量将其压平
对内：
在满足需求的前提下尽量设计得简单，因为我坚信代码越简单， bug 越少。所以我
基本上使用 k/V 形式，这样也能够充分使用框架的特性，有特殊需求如标签等需要传数组，
如果是 web 表单提交，直接加 key 后面加[]
提交，如果是 ajax 等，将数组序列化成字符串，挂载到指定 key 下，这样既简单也不失灵活性。
如果是移动端 api ， response 返回的 json 我也会尽量将其压平，因为 JAVA 是静态语言，嵌套太多，
java 需要构造很多的数据对象，非常麻烦。
这是我两年多开发来自己的一些总结，仅代表我个人的观点。
我吐槽其实也不仅仅是技术上的问题，就像评论说的带有自己的一些偏见，
因为前端年纪比我小，开发很激进，觉得自己会一点 angular.js, vue.js 就像是
走在了科技的前沿，说国内使用的技术，国外早就已经淘汰了。太过理想化，很多
细节又缺乏考虑，好几次出 bug 调试了半天，发现是路径写错了。
对待产品像是自己的试验场。活脱脱一个当年的自己，这也是我不愿争执的
一个最大的原因。
也非常感谢各位的指教与批评
 |
1
qiayue 2016-07-20 21:37:32 +08:00
哇擦， PHP 处理 json 不是最方便的嘛
字符串 json_decode 成数组或对象，如果这一步都转不了直接返回错误信息即可 然后分层验证，从外到里 |
 |
2
czheo 2016-07-20 21:38:28 +08:00
前后分离当然用 json ，嵌套太多是 schema 没设计好，不管 json 的事。
|
 |
3
airyland 2016-07-20 21:40:48 +08:00
如果请求数据需要嵌套 3 ， 4 层，感觉设计有点问题吧。
一般都按照后端数据结构来，如果后端结构没这么复杂，那么这显然就是有问题的。 事实上对楼主公司的协作流程表示不理解啊，后端设定接口啊，写好文档给前端就行了，为什么是前端来设计传值格式啊？ |
 |
4
Mirana 2016-07-20 21:55:26 +08:00
按照业务实体写接口，别把所有的东西都塞到一个接口里去了
|
 |
5
limengwei 2016-07-20 22:03:47 +08:00 via Android
图样
|
 |
6
Pastsong 2016-07-20 22:04:12 +08:00
json_decode json_encode 不要太方便
|
 |
7
smithtel 2016-07-20 22:05:34 +08:00
楼主是怎么处理多级菜单的？这种难道不好处理吗，而且，验证这种事情，主要还是交给前端。后端验证的数据，要求前端放在第一层就好。
|
 |
8
ck65 2016-07-20 22:06:28 +08:00
看主题的描述有种这个 JSON 体积足足有 1MB 的既视感。
|
 |
9
ByZHkc3 2016-07-20 22:10:43 +08:00
前端设计接口？楼主你疯了吧
|
 |
10
orvice 2016-07-20 22:10:58 +08:00
RESTful 一般传输格式就是一个 json 串....
这很清真... |
 |
11
yangtukun1412 2016-07-20 22:12:15 +08:00 via Android
@smithtel 靠前端验证数据，你在开玩笑吗…
|
 |
12
YuJianrong 2016-07-20 22:24:36 +08:00
前端设计接口有什么不对？后端在比前端功能更丰富的语言和调试环境下居然连前端需求都不能满足，那才真是醉了。
当然由于业务复杂所以某些场景需要接口沟通和调整也是需要的。 不过我话就放这了，后端设计接口前端用的公司都是渣（是的，包括我司）。要想做到一流用户体验的互联网产品，不改变思想可是绝对不行的。 |
 |
13
cevincheung 2016-07-20 22:25:12 +08:00
```
if (!$this->_validate(Request::all())) return [ 'error' => 'fuck' ]; ``` |
|
14
smithtel 2016-07-20 22:25:36 +08:00
@YuJianrong 我指的验证是 ajax 方式。
|
 |
15
learnshare 2016-07-20 22:28:30 +08:00
正常来说，前端 /客户端发送到服务器的 JSON 一两层就可以了。一般是：
key: value key: [{ key: value }] 第二种都不是很常用了吧。 |
 |
16
sunmonster OP |
 |
17
iyaozhen 2016-07-20 22:44:59 +08:00 via Android
楼主吐完槽怎么就不见人了。
猜测是楼主需要校验各个数值的正确性。 虽然 json 可以转成数组但在获取数据时需要大量的 isset 判断值是否存在，然后还要判断值是否符合要求。之前也遇到过这种问题，可以封装一个数组获取值的方法，需要用到值的地方再获取值做校验。 |
|
18
iyaozhen 2016-07-20 22:48:49 +08:00 via Android
@sunmonster -_-|| 楼主居然出现了。那你这种情况基本上是沟通问题了。😂
|
 |
19
tinyproxy 2016-07-20 22:55:23 +08:00
@sunmonster 不了解你的业务，但真的有那么多东西需要用事务来保证数据一致性么。。。
|
|
20
sunmonster OP @tinyproxy 确实是需要的
|
 |
21
hasbug 2016-07-20 23:09:14 +08:00
目前我们也这么干，我是一个前端，后端更愿意输出 JSON
|
|
22
hasbug 2016-07-20 23:11:56 +08:00
哦，刚细看了下，这个时候我认为应该是后端决定接口的需要数据，尽量从接口设计上去简化。
|
 |
23
billlee 2016-07-20 23:17:59 +08:00
@iyaozhen 这还是 php 弱类型的锅啊，你看 python 就不需要 isset. 昨天刚填了一个 json_encode 造成的大坑，多层的 array, 里面的某个 value 编码出错，然后 php 在那个 value 的位置上默默填了 null.
@YuJianrong JSON 是 JavaSecript 原生的，其它语言使用 JSON 可能不如前端方便，所以我觉得如果用了 JSON, 那前端应该要去兼容后端。 |
 |
24
cheneydog 2016-07-20 23:18:39 +08:00
我认为这么做是对的， lz 反而错了。
|
 |
25
janxin 2016-07-20 23:29:40 +08:00
|
|
26
YuJianrong 2016-07-20 23:36:17 +08:00
@billlee 在我看来这和什么格式没关系。 JSON 只是一个大家都方便使用的格式而已（虽然 Javascript 尤其方便），即使是后端，我以前写 python 用 XML 前后通讯，等写完就吐血了，用了 JSON 觉得大家都很开心。
只是 API 的定义应该从前端开始，毕竟和用户接触的是前端，只有前端才能解构用户的需求。后端设计 API 前端使用，做出产品后再想做用户体验优化，那简直就是噩梦（是的，我司就这样）…… |
|
27
YuJianrong 2016-07-20 23:37:27 +08:00
@janxin 所以我提到双方要沟通来调整 API ，从后往前太被动了。
|
|
28
janxin 2016-07-20 23:50:28 +08:00
@YuJianrong 同意
|
 |
29
msxcms 2016-07-21 00:01:26 +08:00
应该后端主导开发
|
 |
30
xjp 2016-07-21 00:18:37 +08:00  1
1. 前端定 api 接口没有问题 毕竟最终这些接口是给前端用的 后端是实现这些接口 项目大点 前端需要哪些 api 接口后端都不一定搞得清楚
2. 如果嵌套太多 是数据结构设计的有问题 一般来说 返回值的 json 三四层还是非常常见的 3.1 数据返回值几乎都是 json 格式， restful 风格就是推荐使用 json 3.2 基于 3.1 上传参数的时候 使用 json 代替 formurlencoded 或者 xml 是历史的选择，而且 xml 确实已经差不多快被淘汰了，虽然 formurlencoded 还是大多数， 4. json 比 formurlencoded 简单的键值对更加灵活，对前端开发更加方便 |
 |
31
ferock 2016-07-21 00:51:36 +08:00 via Android
1. 沟通问题
2. 如果你允许对方主导开发，你又懒得沟通，掉坑实属于活该 3. 不管如何嵌套，数据结构合理性最重要， db 或者 api 都需要合理 4. 明显最重要的和老板沟通，你也不擅长 5. 目测你呆不长，而且走的时候依然觉得问题都是别人造成的 |
|
32
sunmonster OP @ferock
@YuJianrong 你说得很对，我也知道很多需要沟通，但是那也要看人，因为他让我觉得我在质疑他的能力。难道你们在项目中前后端都一直沟通得很顺畅？我不想争执是因为我明显感觉到这样既浪费时间，也不会有结果 |
 |
33
rubyvector 2016-07-21 08:25:35 +08:00
多重数据有时候难以避免.看你们沟通的方式.至于数据校验,只要沟通清楚,思路清晰,本身是没有影响的.
当然,楼主是个很有责任心的人.要有些完成任务的,才不管数据校验这种苦逼事呢 |
 |
34
flydogs 2016-07-21 08:27:05 +08:00
不是后端设计 API 嘛？
|
 |
35
shinwood 2016-07-21 08:33:02 +08:00
为什么前端想主导开发？前端兼职产品经理？
|
 |
36
ChefIsAwesome 2016-07-21 08:46:43 +08:00
楼主你讲的是现在后端开发避免不了，而且暂时解决不了的问题。
前端（ web, 手机客户端）的 view 长成某个样子，要你造个 api 提供满足这个 view 的数据。 view 改了，你是改之前的 api ，还是造个新的 api ？之前的 api 是留着，还是删掉不要呢？ web 和手机客户端上的界面差不多，但是需求稍微有点不一样，你是造俩 api ，还是造一个同时满足它们的需求呢？ 最后的结果就是一团乱。 https://www.infoq.com/articles/no-more-mvc-frameworks 这文章的前几段就描述了这种情况。 |
 |
37
Sharuru 2016-07-21 08:48:45 +08:00 via Android
一致性我们是后台存 session 解决的...
|
 |
38
xinyewdz 2016-07-21 08:53:07 +08:00
后端定义初步的接口，然后给前端看一遍，看有没有要补充的。然后在开发过程中在沟通，调整细微差别。
|
 |
39
ericls 2016-07-21 08:54:18 +08:00 via iPhone
你就当是对接第三代 API 吧 这种嵌套多层的 JSON 很常见
|
 |
40
genffy 2016-07-21 08:57:59 +08:00 via iPhone
是个好前端
另，羡慕你们前端不用写 PHP |
|
41
ferock 2016-07-21 09:00:47 +08:00 via Android
@ChefIsAwesome 当沟通出问题的时候，你需要升级问题。领导又不是摆设
|
 |
42
lxguidu 2016-07-21 09:01:30 +08:00
对这种自由格式的数据，一定要订好规则，要不然累死。
|
 |
43
amon 2016-07-21 09:17:45 +08:00
json 不是典型的 K/V 结构嘛？
格式简单、参数和值一目了然、可扩展强，目前应该是主流的 http 请求 /响应数据格式吧。 另外这种工作问题，解铃还须系铃人，最好还是当面和他沟通清楚就行。 |
 |
44
Felldeadbird 2016-07-21 09:19:07 +08:00
设计和沟通问题啊。为什么前端会一次性发这么大的 json 结构。去和他说一下。
|
 |
45
aksoft 2016-07-21 09:20:38 +08:00
这东西还用问前端？他只告诉你他需要什么东西，你给他，数据结构是你定的。有些东西是不能动的，说别的都是扯淡。
|
 |
46
herozzm 2016-07-21 09:20:46 +08:00 via Android
没明白 LZ 到底吐槽什么， json 和前端交换，后端没法保证他们提交过来的数据是你理想中的吧，你管接收和输出即可，那么多话干什么
|
 |
47
iyangyuan 2016-07-21 09:24:08 +08:00 via iPhone
没办法，从某种意义上来说，这也是程序员工作的一部分，甚至是一大部分
|
 |
48
wizardoz 2016-07-21 09:25:43 +08:00
楼主你需要的是 json schema
|
 |
49
honam 2016-07-21 09:27:51 +08:00
没什么问题吧。。。
|
 |
52
Light3 2016-07-21 09:39:08 +08:00
三四层还好吧 都带上 KEY 别 0 1 2 3.
|
 |
53
ghostsf 2016-07-21 09:49:54 +08:00
前端是产品经理吗？
|
 |
54
penjianfeng 2016-07-21 09:59:32 +08:00
嵌套太多肯定是很坑的的一件事,尤其是像 php 这类弱类型,当年我也是吃了不少坑,如果用了 go,解析 json 杠杠的,哈哈,字段类型不行解析都通不过,我直接报错了,省了好多代码,哈哈哈哈
|
 |
55
tairan2006 2016-07-21 10:12:49 +08:00
json 确实不如 xml 好做校验，不过也还好吧。。别设计太多层啊
|
 |
56
reus 2016-07-21 10:14:31 +08:00
有这样的前端，后端不知道多省功夫，连 api 都不用你想。
当然， po 主水平不足，享受不了了。 |
 |
57
chairuosen 2016-07-21 10:29:41 +08:00
我觉得是你的问题
|
 |
58
chztv 2016-07-21 10:37:54 +08:00
其实二三层的 json 还是挺多的，我们公司的后端都是文稿接口，简单和文稿里包含各类媒体文件，图片、视频等，图片有自己的服务器，视频也有，当文稿中一插入媒体文件，这 json 的层级马上就上去了，一个图片还会包括各种参数的,URL 地址的拼接（照我的意思直接返回一个 URL 不是很简单，但当时设计的人光一个 URL 就返回 N 个 Key ，什么 path filename server ，一定要在前端自己拼，一张图片还好，但往往一篇文稿几个图，十几个图真是），唉……
当然前端都已经写了方法，这些都不是问题 |
 |
59
w99wen 2016-07-21 10:41:46 +08:00
楼主你用 MJExtension 配合 json 解析出来的数据。很方便的
|
 |
60
Patrick95 2016-07-21 10:41:50 +08:00
我觉得 json 很多层很正常啊，我之前用过豆瓣的 API ，他返回的 json 就好几层。
|
 |
61
ichou 2016-07-21 10:43:08 +08:00
为什么不拉着他一起好好看下 RESTful
|
 |
62
lwbjing 2016-07-21 10:46:51 +08:00
楼上说的都是。。还有页面上的东西是不是可以重构下，这么多层级的数据，是不是可以分块处理的？
|
 |
63
pangliang 2016-07-21 10:50:08 +08:00
我还是那句得罪人的话: 你哪来的自信吐槽别人?
|
 |
64
Xuanwo 2016-07-21 11:00:00 +08:00
用 json 很清真啊，有啥不好？
|
|
65
ichou 2016-07-21 11:02:03 +08:00
楼主说的是提交的时候用 json 提交吧，如果返回 json ，我觉得没有什么可说的，嵌套多少层都是你们业务逻辑上的事儿。
但是 POST 使用 json 的意义在那里， x-www-form 不能满足需求？前端因为技术限制不能传 K/V ? json 可以压缩传输大小？ 而且 K/V 的方式也可以嵌套啊，不喜欢嵌套也可以约定对复杂的键值 json 化 前端使用 json 的提交导致的不是技术层面的难题，而是这种设计本身不符合很多 PHP 框架对 POST 请求的设计初衷，那也就意味着很多现成的东西不能用，因为前端一时兴起，后端就要自己去花很多不必要的时间做封装 而且这样绕弯子的方式真的会更健壮吗？ @orvice RESTful 和 json 并没有半毛钱关系 |
 |
66
unknownservice 2016-07-21 11:04:14 +08:00
口说无凭，拿例子出来让大伙分析一下到底谁错了。
|
 |
67
icyleaf7 2016-07-21 11:08:10 +08:00 via iPhone
json scheme ，可以帮你解决问题
|
 |
68
repus911 2016-07-21 11:12:34 +08:00
不要让前端设计接口...
|
 |
70
ZnZt 2016-07-21 11:14:59 +08:00
请求的参数用 K/V, 回包的数据用 json 啊
|
 |
71
aprikyblue 2016-07-21 11:24:46 +08:00 via Android
难道不应该是 前端告诉后端需要哪些功能的 api ，以满足需求
后端告诉前端这些 api 需要什么数据，并简化接口 返回数据用 json ， js 解析起来挺方便。 提交用，验证起来，真的挺烦 |
|
72
ichou 2016-07-21 11:26:05 +08:00
@wizardoz 不应该是这样么，或者是通常的设计里面不是这样么？
你是说的用 form 表单提交不合适吧，但是那个貌似应该是 form-data 即便你是使用 ajax 请求后端，或者后端请求其他 API server, 如果是 POST 或 PUT ，你的参数依旧还是用的 x-www-form ，通常并没有人想楼主的前端一样再用 json 包一下 PS ： 就算你用 JSON 来传输，你的数据包最外层呢？ http 协议里面并没有 json 这个选项，所以你的 json 最终还是作为一个键值对的键值传进来的。。。这样是不是更容易理解这个前端到底做了一件多无聊的事情 |
 |
73
Immortal 2016-07-21 11:44:39 +08:00
不要让前端设计接口+1
|
 |
74
chuangbo 2016-07-21 12:25:06 +08:00
很多年前 backbone 默认所有数据 post 都是 json 的了， json post 是比 http form post 更高级的方案。
扁平是很难组织数据的。 |
 |
75
Rand01ph 2016-07-21 12:30:23 +08:00 via iPhone
巴不得让前端设计接口……
|
 |
76
jimmyye 2016-07-21 12:43:19 +08:00
可以看看 Facebook 的 GraphQL ： http://graphql.org
>Query responses are decided by the client rather than the server. A GraphQL query returns exactly what a client asks for and no more. |
 |
77
Clarencep 2016-07-21 12:56:45 +08:00
安利个 PHP 的库： https://github.com/clazz/php-typed-sanitizer
轻松搞定数据校验~ |
 |
78
ragnaroks 2016-07-21 13:16:08 +08:00
因为 ajax 目前无法提交文件(没用表单),所以我将文件 base64 后作为字符串提交...
有一次别人发个图并附加一个"?",我一看居然提交了 7M 多的 json 字符串. |
 |
79
shimanooo 2016-07-21 13:19:38 +08:00
think linearly ==> think recursively
lz 还是要学习一个 |
 |
83
finian 2016-07-21 14:18:03 +08:00 2
- 既然选择了结构化的数据传输方式，当然就是按照业务逻辑来建模数据。只要符合业务逻辑语义，数据嵌套多少层都没有问题；
- 如果产品目前只有一个端，由前端驱动 API 设计并没什么问题。道理很简单，由需求方驱动，合作会更容易进行。人家要什么你就提供什么，这样前后端集成起来就快了。如果后续还有其他端需要接入，可以提供新的统一 API ，也可以继续给每个端提供独立的 API （还是由各个端驱动）；你可能觉得这样就不那么通用了，然而过早设计通常并没有什么卵用，特别是在快速迭代的项目，几个月后接口可能都面目全非了；预留一定的灵活性就可以了，毕竟产品快速上线才是第一要务； - API 不应该和后端资源（特别是数据库）紧耦合。 API 对于后端来说就是一个 View ，对于相同的资源，后端应该可以为不同的端提供不同的 View （ API ）。「因为数据太多，需要插入很多表，如何保证数据一致性？」这个问题和 API 设计完全没有关系，恰恰说明你设计 API 的思路还是「面向数据库」，你应该恨不得把所有 API 都设计成数据库的 CRUD 吧。然而你最终提供的 API 不应该和数据库结构（知识）有半毛钱关系，要不以后调整数据库表结构了、要分库分表了、要换数据库了、甚至不用数据库了，该怎么办？改 API 吗？ - 把你提供的 API 当作产品一样对待，你就知道该怎么做。满足用户（ API 调用方）需求、用户用得爽的，才是好产品； - 楼主表面上提了个技术问题，实际上是对对方「想要主导开发，而且比我要受到老板信任」感到不爽。抱怨无用，多互相沟通、多互相学习、自我提升才是正道。 |
 |
84
jixiangqd 2016-07-21 14:25:26 +08:00
使用 json schema 做验证。。。最方便。。。
但是强烈建议不要用 php 搞 json ，空对象（数组）返回类型不稳定（[]or{}），巨坑无比。。。 PS ： php 是最好的语言 |
 |
85
jy02534655 2016-07-21 14:28:38 +08:00
我就是前端，我觉得合作开发最重要的就是沟通吧，开始沟通是麻烦点，后面只要按以前的套路来就行了。不清楚楼主是什么样的业务导致了嵌套太多的问题，总之多沟通多想办法。数据校验肯定是要多重验证的，前端校验了服务端也要校验，毕竟是面向接口编程，数据安全性很重要。
|
 |
86
f0rger 2016-07-21 14:45:33 +08:00
前端设计接口怎么了？如果设计不合理，你们可以沟通协商啊。
你这信息不太足，猜测就是一个接口提交了太多的数据，而后台需要解构这些数据到不同的业务处理逻辑中，但是因为数据太多，很难做校验。 其实这种情况是可以拆一下的，后端把各业务做到独立的接口中，对现在的前端需求，做一个超级接口对前端公开，接收到了 json 参数解析，分别把相关逻辑数据透传给各个业务接口处理，并在对应逻辑中做参数校验，处理完了再返回结果。 拆不开的话就要看是不是设计有问题了。 当然如果是完全不想干的业务数据，就没必要聚合到一个接口里面去了。 |
 |
87
xujif 2016-07-21 15:32:14 +08:00
@finian 如果完全交给前端设计 api ，实际上是把前端仅仅作为 MVC 里的 V ，这样的轻前端模式其实会带来很多问题：
1 ：数据缓存，不同维度的数据实际上缓存力度不同，造成缓存命中大大降低，简单的例子就是收藏功能，如果前端驱动，他肯定巴不得你给他一个是否收藏的字段，这样造成整个页面字段不能缓存。 2 ： schema 修改频繁，前端页面增加减少功能都会要求 api 进行修改。 3 ：信息冗余。按照页面给数据肯定会造成数据的重复传输 所以我觉得还是胖前端比较好。 domain driven |
 |
88
imdoge 2016-07-21 15:44:41 +08:00
复杂的提交我觉得用 json 而不是键值对没什么问题， angular 的 post 默认就是 json ，而不是像 jquery 那样
|
 |
89
sudoz 2016-07-21 15:46:16 +08:00
跪求前后分离，跪求 JSON
|
 |
91
barbery 2016-07-21 16:18:19 +08:00
我觉得是接口没设计好，你把本身属于 N 个接口的操作整合的一个接口，当然会存在深层嵌套啊，解决办法，要么把接口拆分细点，要么就处理的时候分层校验，这段嵌套属于哪个业务类的，哪个业务类负责校验
|
 |
92
pathbox 2016-07-21 16:19:29 +08:00
你和前端应该约一下
|
|
93
sunmonster OP @finian 哈哈，确实被你说中了
|
 |
95
sfree2005 2016-07-22 08:20:20 +08:00
@jimmyye
@sunmonster @jimmyye 提到 GraphQL, 就是要解决楼主的问题的。 GraphQL 就是介于 前端和后端 的中间件，可以让前端要他想要的， 但同时又保证了后端接口尽可能的简单扁平。这种新鲜事物挺适合你公司里前端激进的性格， 可以让他配合 angular 或者 vue.js 使用。 |
 |
96
ryanking8215 2016-07-22 09:10:09 +08:00
http://jsonapi.org/ 哪个例子不是 2,3 层啊....
|
 |
97
lixm 2016-07-22 09:15:12 +08:00
数据校验用 jsonschema 啊
|
 |
98
lurrpis 2016-07-22 09:55:20 +08:00
too young
|
 |
99
Esay 2016-07-22 11:38:18 +08:00
可以考虑用 protobuf 来统一前后端数据的定义
|
 |
100
frozen2013 2016-07-22 11:47:54 +08:00
看到有人提到 GraphQL ，正好最近在研究这个，说两句：
楼主公司的前端用 angular/vue ，作为前端想要后端传 json 数据无非是和 angular 的 scope 里的对象好做对接，特别是多层嵌套结构的 json ，这样的话前端 parse 和重新组织对象结构的力气都省了，所以前端极力想让后端给他方便。 GraphQL 推出了一套新的结构化语言，看上去非常优雅，但是它需要后端提供的接口跟传统 rest 的方式已不一样，例如它的 query 可能是这样的： http://serverxxx.com/api?query={user(id: 1) {name,age,post,friends {name,age}}} 这对于用 angular/vue 的前端来说，现有框架是与 rest 方式结合的最好，用了 GraphQL 他们也需要写额外 ajax 代码来适配。你们觉得一个这么想图方便的前端，乐意做？ 再则， GraphQL 是 facebook 的产品，推出来刚好一年，生态圈目前还不算成熟。 如果你是 react 前端， nodejs 后端，施行起来至少还有官方的工具和库来帮忙，但用 PHP ，估计很多时间都得用在自己摸索了。。。 |
Select Language