时间：2021-07-01 10:21:17 帮助过：15人阅读
最近公司项目需要整改成前后端分离，为以后提高开发效率，和多设备兼容做准备。
本人是负责后端数据处理，使用PHP语言，Laravel框架
在开发过程中遇到一个这样的问题，希望有经验的朋友能帮我解决下，谢谢。
问题如下：
因为数据表设计关系，
比如：
click：浏览表
answer：回答表
topic:提问表
user:用户表
tags:标签表
如图，画出红线部分，
我个人倾向于，分开读取，每个都是一个api，如：
click http://x.com/click?k=1&b=2
answer http://x.com/answer/count?id=5
topic: http://x.com/topic/5
tags: http://x.com/tag?tid=10
user: http://x.com/u/5
以上只是简单备注，并不考虑链接
对于上图，我对前端提供 5个api，这样他可以根据条件自由获取，更加的是可重用，其它页面需要用什么，直接拿过来就可以。
就在此处和前端发生分歧，
前端希望我只做一个接口，获取所有页面上的信息，格式大致如下：
{
title:....,
username:......
tags:......}
对于这种要求本人也思考和纠结很久，两种方法各有利弊，上面两种方法以先后顺序称为1，2
方法一：
缺点：
1、需要开发的接口众多
2、服务器来回传输可能会造成网络资源的浪费
有点：
1、可以提高代码重用率
2、可以优化后端代码
方法二：
缺点：
1、一个提问数据需要拿出很多非本身数据，如用户，标签等，如果我遇到很多这样的数据获取呢，比如文章数据，比如商城数据，我需要每次都根据我自己的循环再来一个个拿出user数据，感觉不太合适
优点：
1、减少前端代码工作量，特别是不需要他们去执行逻辑
思考再三，也没拿定主意，所以希望有遇到过类似问题的朋友能给我个意思，十分感谢。
PS：基本上只是使用angularjs+laravel，非使用nodejs中间层，淘宝ued已看过，才疏学浅不是太懂，只打算先不使用nodejs中间层
最近公司项目需要整改成前后端分离，为以后提高开发效率，和多设备兼容做准备。
本人是负责后端数据处理，使用PHP语言，Laravel框架
在开发过程中遇到一个这样的问题，希望有经验的朋友能帮我解决下，谢谢。
问题如下：
因为数据表设计关系，
比如：
click：浏览表
answer：回答表
topic:提问表
user:用户表
tags:标签表
如图，画出红线部分，
我个人倾向于，分开读取，每个都是一个api，如：
click http://x.com/click?k=1&b=2
answer http://x.com/answer/count?id=5
topic: http://x.com/topic/5
tags: http://x.com/tag?tid=10
user: http://x.com/u/5
以上只是简单备注，并不考虑链接
对于上图，我对前端提供 5个api，这样他可以根据条件自由获取，更加的是可重用，其它页面需要用什么，直接拿过来就可以。
就在此处和前端发生分歧，
前端希望我只做一个接口，获取所有页面上的信息，格式大致如下：
{
title:....,
username:......
tags:......}
对于这种要求本人也思考和纠结很久，两种方法各有利弊，上面两种方法以先后顺序称为1，2
方法一：
缺点：
1、需要开发的接口众多
2、服务器来回传输可能会造成网络资源的浪费
有点：
1、可以提高代码重用率
2、可以优化后端代码
方法二：
缺点：
1、一个提问数据需要拿出很多非本身数据，如用户，标签等，如果我遇到很多这样的数据获取呢，比如文章数据，比如商城数据，我需要每次都根据我自己的循环再来一个个拿出user数据，感觉不太合适
优点：
1、减少前端代码工作量，特别是不需要他们去执行逻辑
思考再三，也没拿定主意，所以希望有遇到过类似问题的朋友能给我个意思，十分感谢。
PS：基本上只是使用angularjs+laravel，非使用nodejs中间层，淘宝ued已看过，才疏学浅不是太懂，只打算先不使用nodejs中间层
呃这个问题.. 我也答一下吧：
我前后端都做。
我有的时候用原生(没有模版引擎)，有的时候用mvc(模版分离);
angularjs 也用过一段时间
我个人感觉我更倾向于 自由度更高的 API 接口。
1.使用场景一（专题活动）
专题活动 的个性化很强
每次做公司专题活动页面。不会每次都去 找 后端 让他写个这次我所需的完整输出格式json吧。
若是后端已经提供了 自由度更的完整的api接口 那我前端想咋搞咋搞。只要所需的功能不超出提供的api那就没有问题。
就算这次活动搞不成了 飞机了。 也不会和我后端有任何影响，我也不用去删除一些 沉积的接口。
就好比 微信提供的 api 它提供的 自由度就比较高。 你按你的需求去调就好。 不可能 你需要个什么 还要 微信再给你提供接口吧。
所以你先看看是否给前端提供了 自由的 api
再问问他们的想法 是觉得 多个请求麻烦还是什么
语文不好
1.代码可维护性必须优先，想想系统升级，接口文档等等的问题。
2.页面必须尽快加载出来数据展示给用户。
3.多次请求会造成网络资源的浪费，多余的内容会造成数据库性能的浪费。
4.服务器性能足够好的情况下，多个AJAX请求获取数据要比只让一个PHP执行一堆SQL要快。
所以，我的答案应该是比较清晰的。
UPDATE:
这个问题确实也曾经困扰过我。。。
毕竟最优解和最合适的解还是不一样的。。。
毕竟要考虑前端后端的技术水平、实际访问情景、服务器性能等等。。。
不过总的来说，分离的好处是更明显的，毋庸置疑。。。
从用户的角度来说，他们需要更快的看到数据。。。
从代码的角度来说，分离能让后端代码更加清晰。。。
至于前端。。。
额，貌似确实是把前端的代码弄复杂了，并且需要发多次请求。。。
不过既然决定要前后端分离。。。这就是代价啊。。。
分情况，我们这边两种都在用。
如果是和某具体业务内容高度耦合的数据就单独建个方法，拿到全部数据后打包回传，这样减少请求次数，同时减少无用数据。
如果是较为通用的数据，那就用通用方式来做。
另外，你的前端之所以不喜欢第一种方式，原因在于你们缺少一个自己的前端工具库。
我目前是通过$.dataCache(['Person','User',……])这样的方式直接拉取所有自己需要的资源，拉取过程中优先使用前端缓存数据，如果没有则发起异步请求。同时，还提供了跟复杂的api来提供根据指定参数查询或获得指定列的效果。如果你们有这样的库，那你们的前端就不会抱怨了。
写一个请求合并的php脚步，接受形如 http://x.com/combo
?click=/click?k=1&b=2
&answer=/answer/count?id=5
&topic=/topic/5
&tags=/tag?tid=10
&user=/u/5
返回json
{
click: [...],
answer: [...],
topic: [...],
tags: [...],
user: [...]}
PS: 那个url里的参数主要urlencode
小前端一枚,
在我看来,前端调用后端的接口是为了拿数据是毫无质疑的,但是我倾向于第二种获取方法.
一:可以省去那么多的请求,一个请求就可以得到我所有的数据.
二:分散开请求之后得到的数据在渲染的时候需要多重处理,我用avalon,那么一个请求,回来一个对象就渲染了,如果是多个请求,我要对多次请求的数据,重复多次塞到一个对象中,至于为什么是一个对象,一个区域内相同的属性,我习惯塞到一个对象中.
三:在我看来(个人想法,不喜勿喷),后端就是提供数据的,前端的重心在于展示,不在于处理数据,所以后端应该把数据处理好相应的格式,吐给前端,小修小改我觉得不是问题.你可以在后端用辣么多SQL把数查出来,拼一起给前端.
至于你说其他地方可能也用到这些小接口,我个人认为前端调用你的接口可以不同,但是你想查的东西,操作同一个表的时候的SQL是相同的,这一部分是可以重用的啊.
个人开发感触,不喜勿喷哈
我觉得不同业务应该使用不同接口，哪怕你服务器端处理方式相同。
也就是说两个c层入口可以公用一个服务层接口。
通常情况下，就可能返回完整的信息，第一种思路拆的太细了
node中间层，koa异步框架，你值得拥有，爱咋整咋整
推荐看看jsonrpc，支持一次网络请求多个接口调用
菜鸟也来答一答
一直从事的都是移动办公APP开发，页面数据当然是分离的便于以后多平台使用。
数据接口细分(API)当然是件好事,便于以后拓展维护，但是这样会导致前端获取复杂数据需要多次请求，
前端优化里面有个很重要的点就是减少请求次数，这样的网络资源浪费肯定是不行（请注意这是不行的）。
之所以称之服务器，并不是它和设备有物理隔离，而是因为它“被动”而且“不易变”。
设计服务器软件程序的时候一定要考虑到
1）扩展性 -- 你的业务将来会不会拓展到别的设备上，甚至是还没出现的设备。
2）稳定性 -- 你的业务在以后环境变化、需求变化的时候需不需要改动原来的业务逻辑和接口。
3）鲁棒性 -- 随着时间的推移、由于服务一旦发布，修改老API几乎是不可能的事情，这一点上，做错的代价很有可能大于不做。
当然还有可用性和确定性。
但是当考虑到现实情况（开发能力、资金、时间）不可能在开发中面面俱到，这个时候就要充分考虑：
1）软件性质 -- 到底是一个demo还是原型还是成熟的商用业务软件
2）项目关键 -- 进度还是成熟度？
再到你做的这个功能上：
1）到底以后会不会重用？answer是不是在内容本质上就包含了title而不是形式上?
2) 是不是做一个facade模式的brief接口更好？
3）还是说这个功能暂时就在这里会用到一次，以后重构也来得及（重构 > 详细设计 ？）
4）最紧要的需求是什么？老板要求你们多少时间内完成？这个东西以后会被删掉吗？
以上，有的时候光光好是没有意义的。
对于你的那个例子,最好当然是:
每个页面展示部分都有各个细的接口可以单独获取。
有一个整齐的详细接口和一个只有诸如标题序号等的简介接口。
每个接口都有它的列表（复数）、查询、删除、更新接口。
更暴力的方法，前端发送schema到后端统一接口来根据schema来生成视图（DSL）
同时这些接口还要有详细的权限机制和过失机制
对于数据渲染（指的是渲染到json还是xml还是html还是plain text) 这些，应该有统一的机制，例如读取http-header中的attribute或者是API采用.json .xml .html后缀
甚至在某些场合，api列表和形式可以由客户端和服务器端协商使用，例如atom, xml-rpc, xml-json, soap, restful 或者是自定义的一些格式
等等。。。
所以，不需要一个最优解，能用就用，赶紧做出来然后剩下的交给硬件和摩尔定律。逃）