>  Q&A  >  본문

javascript - 关于WEB前后端分离,服务器端数据返回问题

最近公司项目需要整改成前后端分离,为以后提高开发效率,和多设备兼容做准备。

本人是负责后端数据处理,使用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中间层

PHPzPHPz2751일 전1196

모든 응답(11)나는 대답할 것이다

  • PHP中文网

    PHP中文网2017-04-10 16:25:39

    之所以称之服务器,并不是它和设备有物理隔离,而是因为它“被动”而且“不易变”。
    设计服务器软件程序的时候一定要考虑到

    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 或者是自定义的一些格式

    • 等等。。。

      所以,不需要一个最优解,能用就用,赶紧做出来然后剩下的交给硬件和摩尔定律。逃)

    회신하다
    0
  • 취소회신하다