关于服务器开发，对外接口统一性

[RayDoyle]

今天和其它设备的同事讨论接口问题，他突然提到。
是不是可以对外只公布一个接口，然后根据传入的flag字段，判断这个接口是要做什么，然后服务器执行对应的逻辑，并返回数据。
因为做过挺多的项目，从来没有见过这种方式，所以果断的说了不能。但是他问起原因的时候，感觉自己也不能说得太明白。只能大约的说出一些自己觉得没有太理直气壮的理由：这个加大了服务器的接口代码复杂度（但是后面想了一下，可以一种逻辑专门建一个类写一个方法来解决），不方便后期的维护，不方进行性能监测。但是没有一个我觉得非常非常充分的理由。
所以想请问一下，这种方式不可行的理由在哪里呢？

还有一个小问题，这个同事也提出过，服务器返回的处理结果代码中，如果服务器错误，则返回负数，这样就只需要判断代码小于0，就知道是错误了。但是，我做过的所有项目，也从来没有过处理结果代码为负的情况。而且我在网上看了资料，服务器的接口返回自定义代码中，没有一个为负数的。
但是在我的想法中，这样做其实也没有什么大的问题。所以我只能以服务器的规范基本不会用负数表示处理情况，这种想法来说服自己。
那么用负这种方式是不是合理呢？什么没人用呢？

[瘦死的黑骆驼]

第一个问题：你有用过springmvc吗，dispatcherServlet就好像是一个大的路由，把你所有的请求进行分类，然后转发，要是统一接口的话就和这个有点类似了，如果业务不是很复杂，这样我觉得是行得通的，但是如果过于复杂或者传递的flag太多可能不太好控制，容易出错 第二个问题中的自定义代码，正负感觉没什么关系，只要能正确表达就可以了，个人意见

[RayDoyle]

现在就是用的springmvc。这个逻辑我道是了解。。。只是对外接口都这么做的话，有什么弊端，想不到一个很有说服力的。但是，也基本没有见过这样做的。。。最多是一些相似的功能通过flag这种字段进行区分，但是全部接口用一个对外端口，也没遇到过。觉得肯定是有一些比较严重的问题的。
这个代码，好像真的所有大公司都没用过负的。。。所以我也很好奇这点。

[RayDoyle]

引用 1 楼 瘦死的黑骆驼 的回复:

第一个问题：你有用过springmvc吗，dispatcherServlet就好像是一个大的路由，把你所有的请求进行分类，然后转发，要是统一接口的话就和这个有点类似了，如果业务不是很复杂，这样我觉得是行得通的，但是如果过于复杂或者传递的flag太多可能不太好控制，容易出错
第二个问题中的自定义代码，正负感觉没什么关系，只要能正确表达就可以了，个人意见

现在就是用的springmvc。这个逻辑我道是了解。。。只是对外接口都这么做的话，有什么弊端，想不到一个很有说服力的。但是，也基本没有见过这样做的。。。最多是一些相似的功能通过flag这种字段进行区分，但是全部接口用一个对外端口，也没遇到过。觉得肯定是有一些比较严重的问题的。
这个代码，好像真的所有大公司都没用过负的。。。所以我也很好奇这点。

[oh_Maxy]

对外一个超大的接口，功能是可以实现的，但是业务耦合度太高，后期维护成本太高，甚至无法维护。

[浪费七年时间]

ESB、微服务网关这种就是给外部提供一个地址吧，通过路径参数、请求参数进行路由转发，但后端不会只是一个类或者一个项目 错误码正负无非是自己定的，文档齐全就没什么问题，微信小程序也用了负错误码 https://developers.weixin.qq.com/miniprogram/dev/wxcloud/reference/errcode.html

[weixin_43869905]

spring Cloud 的网关 就是 所有请求访问网关 网关在分发

[树成]

没有什么弊端，只是重复发明轮子罢了，http干了这种事情，把所有请求根据url来区分，servlet干了这个事情，用url来区分请求，spring-mvc也干了这个事情。你再去干这个事情，有什么意义呢？ http的请求参数包含的url地址就是用来干这个事情的，结果你自己抛弃这个现成的功能自己去玩一套flag，不觉得多余么？

[亲爱的Joe]

你回答不要那么生硬。对方问你可否只提供一个接口，然后通过flag来区别功能？ 你应该这样回答: 当然可以啦，不过更好的办法就是咱们现在用的办法,你可以把现在的接口当成flag，原理差不多。 这样，前半句体现了你的情商，后半句体现出你对专业理解的深度，堪称完美

[哈希塞特]

那请问你的接口文档怎么提供呢？难道不同flag写不同的参数和返回