客户端接口对接,我那个气啊...

[Zach369]

收藏夹列表:

[
    {
     "id": 2,
     "name": "我的资源收藏夹 1"
    },
    {
     "id": 3,
     "name": "我的资源收藏夹 2"
    }
 ]

现在产品设计 加了个不限.....

然后客户端 非得让我修改接口

[
    {
      "id": 0,
      "name": "不限"
    },
    {
      "id": 2,
      "name": "我的资源收藏夹 1"
    },
    {
      "id": 3,
      "name": "我的资源收藏夹 2"
    }
]

就因为下拉 要多一个不限的选择.......

你们现实中是怎么样的那?遇到过这样的问题吗?

各位大佬.我只是问问大家的意见... 没有别的意思.. 目前已经商量好了,以后这种事情.统一由后端来改. 来返回

[
    {
      "id": 0,
      "name": "不限"
    },
    {
      "id": 2,
      "name": "我的资源收藏夹 1"
    },
    {
      "id": 3,
      "name": "我的资源收藏夹 2"
    }
]

[SilencerL]

遇到过, 一般谁拳头硬就听谁的.
不过我还是感觉这种需求放前端实现比较好.

[geshansuiyue]

积怨已久？

[shoaly]

就现在后面这个 json 挺好, 毕竟 前端不用动, 后端只用多一个 item, 况且产品可能脑抽 还要改字,
不限变成 默认,
默认改成 收藏
收藏改成我的收藏夹
不能每次都升级客户端的

[sodulty]

约定好第一个值是特殊的。许多场景不想新开接口，只能靠约定，缺点是维护成本高

[artikle]

这种一般是后端改的，因为要是返回的不限这种有变动 比如改名字或者去掉这个选项，后端修改发版成本比较小

[liuxey]

像“全部”“不限”这类选项我觉得是 UI 组件的事情，但是具体还是要看谁更硬

[HongJay]

为啥要写死在客户端

[kop1989]

从整体角度上讲，服务器端加的成本更低，而且更通用。
如果是客户端加的话就要涉及到特殊处理，其实会更麻烦。

[KyonLi]

我是能不麻烦后端就不麻烦，在前端分别请求每个分类里的内容然后合并展示，虽然分页加载很诡异但还是能凑合用的

[geekzhu]

@kop1989 #8 好奇问一句，这种情况下，服务端不用特殊处理吗？

[kop1989]

@geekzhu 1 、无论在客户端还是服务器端加，在反过来数据提交的时候服务器端都要特殊处理。
2 、其实楼主的这种情况对于服务器端而言不是“特殊处理”，而是多了一条数据。

[kop1989]

@geekzhu 3 、这个“特殊数据”，其实是服务器端需要的。那么服务器端需要的就应该由服务器端提供。因为这组数据本身是服务器端返回的动态数据。否则如果客户端特殊处理，写死这个“特殊数据”，有差错责任在谁。

[ISSSSSSS]

建议后端处理，这样更灵活。比如改个字什么的。

[mmrx]

我是客户端
这个事情其实哪端做都可以，这个时候就得看谁在群里说得看上去更有道理
一般我都是“说得看上去更有道理”那个

[wolfie]

在哪实现都一样，谁改谁王八。

[geekzhu]

@kop1989 #11
1. 输出的特殊逻辑跟输入的特殊逻辑，不能同一而论吧
2. 就像表面上来看，客户端也只是展示的时候多了一条数据

[xuarongla0000]

发帖的时间都可以改 10 个这种需求了

[kop1989]

@geekzhu 哦抱歉，我审题的问题，我以为客户端还需要上传。
不过如果不谈回传的问题的话，我个人认为还是服务器处理要合理一些。
主要还是因为这组数据是动态返回，前端写死相当于就对这个动态返回的数据进行了“污染”。这种会在日后维护的时候造成麻烦。

[geekzhu]

@kop1989 #12 3. 这句话有点不太理解，服务端展示的数据大部分都是客户端需要的，那是不是客户端自己保存就行了，服务端只负责统计就行

[geekzhu]

@kop1989 #18 嗯，其实这个谁加都可以，看谁成本低吧

[yaphets666]

我觉得 "全部" "不限" "所有" 这种字典值很蠢 不填不就是全部? 清空不就是全部? 还用单独搞一个这个出来?

[des]

@shoaly
@liuxey
@HongJay

单选还行，多选就 gg 了

[newtype0092]

别气，客户端是要为更新发版妥协的，如果内嵌 H5 页面的可以直接让前端改，但如果是原生 UI 还是后端处理下吧，也算为了用户考虑。
要怪就怪产品为什么早没想到要加个不限，这种又不是什么很特殊的逻辑。。。

[shoaly]

@des 多选一样 也没 jj , 多选就是客户端 上传一个 id 数组 , 这个接口本身没毛病

[baozijun]

做成数据字典模块,维护即可

[DamonLin]

建议后端给接口吧，客户端写死的话不方便后面扩展

[zhangchioulin]

这个要看产品规模，DAU 百万的产品我认为这个放在后端比较合适，因为这个量级的产品都有一套全面的后台管理系统，可以控制非常多的东西。比如我司的后台管理能精确到移动端某个活动 Label 的颜色。
如果是产品目前 DAU 不大的话，后台系统不全面的话那就谁改起来简单谁来了。

[huage2580]

我觉得没问题 啊，反正进收藏夹列表肯定带 id 给你吧。这样设计不挺好吗

[zpf124]

我们一般是前端改， 因为许多类似这样的接口我们设计的时候都是不传筛选参数代表查询所有。

所以这里一般前端做一个额外处理，选择全部时，不给后端发这个参数。

[zdt3476]

具体得看更新成本。如果产品后面要修改"不限"这两个字。肯定是放在更新成本低的那方最好

[otakustay]

中间加一层 BFF，爱怎么改就怎么改，不修改后面的实际业务服务

[mendax92]

其实这种东西，前后端改动都不大，我是做前端的，我也建议这种东西 放在后端。这样更灵活。就像平时开发的时候，接口数据提交只是很简单的一条数据，我建议 把数据封装成数组再提交，因为这种需求 谁也不能保证下一次 需求 不是 批量提交。

[suzic]

遇到过，既然客户端不想改，那就我改呗。反正也改动不大。

[chairuosen]

客户端这种不能随时发版的，业务逻辑要后移才能保证灵活性。

[senher]

@mendax92 #32 很赞成

[Nostalgiaaaa]

产品想改文案 "不限" 改成 "全部" 或者后来想做 abtest 。客户端发版等一周，后端十五分钟。从可拓展性来说后端改好一点。而且要是想记录用户操作啥的，打点也方便。

[speculatorA]

不还是多一条数据嘛。。
你后端改到发版，也就 10 分钟的事情？
客户端从改到发版，那是 1-3 天的事情。
你在发这贴，你同事可能在其他位置吐槽你呢。233

[Alexander321]

这个...肯定后端改
因为产品改了一次就能改无数次
增加 item 修改 name..
直接后端做成可配置的 大家都省事

[RJH]

@shoaly 服务端升级，重新发版更加伤啊。

[shoaly]

@RJH 莫非你们公司觉得服务端升级会麻烦到自己人不好,
还是提醒客户, 让客户去升级的方案更方便么?

[dicc]

@yaphets666 下拉跟填空不一样,下拉还得恢复成空

[Woood]

你是不是没有经历过苹果更新版本

[root777]

你有这发帖的时间，还不如去改接口，这是多大脾气的人啊

[des]

@shoaly
我说的多选的问题不是这个
一开始是没有“不限”的，然后后端加了个不限
你想想，选中“不限”的时候是不是应该吧其他的去掉？

[nicevar]

客户端不是前端，上面一些人要搞清楚，这个问题肯定是后端改最简洁，没什么好气的，几分钟的事非得斗气还怎么合作。

[nl101531]

问题不应该出在改需求嗯产品吗。。。。