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

[Zach369]

收藏夹列表:

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

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

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

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

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

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

[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 莫非你们公司觉得服务端升级会麻烦到自己人不好,
还是提醒客户, 让客户去升级的方案更方便么?