标签：
最近开发中，遇到某些情况，比如：
- 是返回一个 int 类型/状态等,前端去做逻辑判断（显示控制/渲染），还是直接返回一个字符串之类的结果（或者其他直接结果）给前端...
- 表单查询是统一用 post+raw,还是说简单的表单不需要 post ，requestBody ，只有复杂的表单查询才这样做？还是说只有新增/修改时，才会采用 post+raw 的形式...
- 当有一个需求/bug 改动，最好(性能，设计合理性等)是前后端配合着改时，是两边改，还是为了兼容，只改后端...
- 第一条，个人觉得，直接返回结果会带来几个问题：
- 如果改数据必须存储到数据库中，会增加没必要的存储空间；
- 增加流量，影响接口网络传输性能
- 结果单一，如果需求改动，接口得增加返回更多得新需求数据，不能复用
- 接口做过多的逻辑判断，会影响接口性能 当然这种问题无非是前端做还是后端做的问题，前端渲染时，去判断这些时同样需要消耗性能去执行。
-
第二条，个人觉得统一比较好，即使影响不大，但一会这，一会那的，写代码时的“注意”成本高（写接口时要去判断是用前者好还是后者好，用接口时要去看接口是前者那样用还是后者那样用）。。。
-
第三条，个人觉得前提是否具有兼容性问题，如果是有，当然兼容性是必须优先考虑的，不过兼容性可能要看改动影响的范围，如果影响较小，后端在原有基础上做兼容改动没啥问题，但如果改动较大，需要从版本上去做兼容，个人觉得此时前后端都得改，而不是某一方硬适配。当然如果没有兼容问题，建议怎么改，对主要的指标（性能，设计合理性，扩展性等）比较好就怎么来，无论谁需要改动。
PS: 哈哈，这里主要是最近一些经历，比如遇到一个问题需要改动时，同事总会说，这样前端需要改动之类的，让我尽量的去适配前端，让我怀疑是我的工作经历不足导致我认知不足，还是同事太顾着前端了
看看网友的一些回答
不知道你说的前端包不包含客户端，就第一条来说，这个字符串需要前端显示的话最好是直接返回， 除非这个显示不会改动不会增加。
因为客户端升级成本还是挺高的，APP 要审核通过才能上线，上线还要用户升级才能生效，增加修改了一种状态后旧版本 APP 就不能正确显示了。
另外可以抓包一些常见 APP 看看， 就拿京东来说， 它的接口返回的东西真是超乎想象的多，甚至一些按钮的 title 都是接口返回的，真就前端只负责渲染那种。
| 问题②，有时候 b 端系统，查询条件很复杂，使用 get 方法单纯 kv 很难实现查询条件。get 传 body 也有坑，服务端有些框架直接把 get 请求的 body 擦掉了，默认拿不到。看阿里云有一个实现就是 get 方法 params=json 字符串这样，符合 get 语义，但是感觉怪怪的。post 不合语义，但是相对来说实现较简单。 如果是网页这种的,前端动一下吧. 如果是 APP 这种还要走正规上架流程的,后端改一下也无妨。 还有，返回什么格式要始终遵循一样的规则，尽可能，谁都不能说那天没出什么差错。 友好协商，积极合作，共创共赢！ |
标签： 来源：
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。