咨询api数据的结构设计

发布于 2022-09-05 05:03:02 字数 500 浏览 12 评论 0

有几个问题:

问题1:api的数据结构怎么设计才方便前端使用呢?
例如代表有没有权限,

有些只会在有权限的时候返回值,

{
access:['163.com','baidu.com'] // 有权限的才访问
}

可能每次都要去别的地方再取一份完整权限表来比对,但是在前端做这个比对也是很麻烦的

有的就会返回多一个标签代表是否有

{
meta:[
 {'163.com':true}
{'baidu.com':false}
] // 有权限的才访问
}

这样简单,但是往往所有数据列出,传输数据比较大

问题2:怎样跟后端沟通设计api的数据结构呢?

应该以一个什么样的原则和方式来跟后端撕逼呢?因为人总会自私,后端也会想省事,尽量节省处理,做最简便的输出,但是前端往往难处理

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

日裸衫吸 2022-09-12 05:03:03
  • 首先,我得说句抱歉,我作为一个追求代码完美精致的人,从来都是想着如何用优雅又简洁的方法处理问题,所以我写的东西追求简洁但是绝对不会因为图省事给其他开发增加麻烦,写的后端结构也尽量不会让前端难以处理。所以,至于撕逼的原则和方式,我真的不太清楚。如果后端实在太烂,我会把前后端的活都自己做了。

  • 至于你第一个问题,我有以下几点想说的:

    • 针对你这个代表是否有权限的例子,我觉得统一权限模型即可

    • 如果只是需要表示某个站点没有权限,直接返回{access: false}即可,前端在请求时候,带上site: 'baidu.com'即可,后端通过查找权限表,返回布尔值

    • 如果要表示多个站点的权限,返回{access: {baidu.com: true, google.com: false}}即可,和之前类似,带上site: [...]即可

    • 而且上面这两种情况,其实可以合并成一个操作,假设后端权限判断用的是A方法,那么,前端传进来的是数组,就循环数组调用A,如果是字符串,就直接调用A。这样,后端返回数据的结构,实际上是由前端控制的。如果前端只想给查单个网站权限,就穿字符串,如果想要多个网站权限就传数组,这样前端和后端都可以灵活处理。如果前端需要另一种数据结构的话,后端也完全不必更新代码。

    • 后端可能每次都要去别的地方再取一份完整权限表来比对,这个没错。由于权限短时间内是不会变的,所以可以考虑使用文件或者Memcached、Redis等缓存权限表,这样可以减轻数据库查询的压力,如果任何操作涉及到权限表的变动,只需要将缓存清除。后端代码里,可以先判断是否存在缓存(且缓存是近期生成的),如果不存在再去找数据表,这样会比较好点。

执着的年纪 2022-09-12 05:03:03

1、主要取决于前端是否会用到 没有权限的域名(即 {'baidu.com': false}这类的数据)。如果不需要,则后端只需要返回已授权域名列表即可;如果可能会用到,则需要返回全部。
2、API返回数据结构,通常都是标准的json格式。至于用[],还是{},基本不会有什么争议点,因为不管哪种,其实对前后端工作量都差不多。主要的一些争议点在于:某些前端、后端都能实现的功能,到底应该谁来做?这个其实也没法一竿子拍死,具体情况,具体分析,宗旨就是:保证性能,保证用户体验。

拿命拼未来 2022-09-12 05:03:03

如果前端页面需要 有权限 和 无权限的 列表 ,那么需要一个总数据。
这时候建议用一个接口实现,[
{'163.com':true}
{'baidu.com':false}
] 。
如果前端只要有权限的列表,那么就只要
{
access:['163.com','baidu.com'] // 有权限的才访问
}
对于后端来说都很简单的操作。
前端希望的也是最好一个接口能搞定。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文