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

[Zach369]

收藏夹列表:

[
    {
     "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 嗯，其实这个谁加都可以，看谁成本低吧