后台仿京东商城接口设计缺陷吐槽篇

办公室刚battle完，忍不住来吐槽一下，先上图，再说需求和接口设计

个人理解的排序：不管是综合排序还是销量排序亦或者是价格升序降序，请求的参数类型应该是下图模式

class SortType {

    companion object{

        val TYPE_PRICE_UP = 1

        val TYPE_PRICE_DOWN = 2

        val TYPE_SALE_COUNT = 3

        val TYPE_SYNTHESIZE = 4
    }
    
}

fun getRequestBody(map:HashMap<String,Any>){
        map.apply { 
            put("type", TYPE_PRICE_DOWN)
        }
    }

事情起因呢，就是咱这后台设计接口，以为需求只有价格升序降序，所以定义一个boolean类型判断排序是升序还是降序，在博主核对接口的时候发现少了综合排序，在和产品确认需求点击综合排序没有弹出下拉框选项后，确定综合就一种排序方式，后台呢给接口设计有增加一种boolean类型判断排序是否未综合排序，后台的排序理解如下：

fun getRequestBody(map:HashMap<String,Any>){
        map.apply {
            put("是否是综合", "是")
            put("是否是降序","否")
        }
        
        when("是否是综合"){
            "是" ->{
                
            }
            "否" ->{
                when("是否是降序"){
                    "是" ->{

                    }
                    "否" ->{
                        
                    }
                }
            }
        }
    }

若干年以后呢，ios的哥们开发是接口传递的参数把是否为综合当成综合降序升序传递参数，这就导致android端和ios端显示排序不一致了，后台一看界面以为自己做了综合降序升序排序，一直认为自己没有任何问题，还闹心的很，估计是自己都忘了自己当初为什么要加这个参数了吧（牛逼的很咱也惹不起，咱就是不理会，跑来水一篇博客）

这个锅该怎么正确的甩呢，两部分：

1.点击综合排序时，ios传综合为false,价格排序为true/false,后台查询的是价格排序而非综合排序（后台以为查的是综合排序降序，自己都没看一眼自己写的代码张口就来）
2.如果一开始后台的接口设计都如我上面理解的一个type对应多个类型就不会有这个问题，当初我还多次要求后台修改接口参数，后台不想改，怎么简单怎么来，所以自己的锅自己背

再提一点，咱这后台的接口没法适应多变的需求，假如某一天需求增加口碑排序，评价排序，咱这后台要怎么写呢？！！肯定是boolean大法再来几个变量，汗…

咱这后台水平怎么样你们自己品，咱也不好说，咱也不敢问，怕打扰他开心的玩游戏刷剧！！咱是能避则避，锋芒过盛惹不起！！！

各位读者有何看法欢迎在下方评论区交流