我应该怎么来设计一个对前台的接口？按照业务还是按照灵活性？

[bcc222]

近期需要开发一个项目，

目前公司现有的接口根据页面来走的，比如：

第一种接口如下：

http://api.xxx.com/getQruery? id=XXX ，itemtype=01
返回：姓名，年龄、体重、身高、建议

http://api.xxx.com/getQruery? id=XXX ，itemtype=02
返回：姓名，年龄、血压、xx、平均血压、脉率。。。、建议

http://api.xxx.com/getQruery? id=XXX ，itemtype=03
返回：姓名，年龄、项目1结果，项目2结果，项目3结果。。。。。（有多少项返回多少项）


第二种接口，如下：：

输入：http://api.xxx.com/getQruery? id=XXX ，itemtype=体重，血压，生化项目1，生化项目2

返回：姓名、年龄、体重结果、血压结果、生化项目1结果,、生化项目2结果

我现在与后台争论的有两个问题：
1、对方说，用第一种方式的话在后期并发量比较大的过程中，比较容易进行设计上的扩展（后台用的java）
2、第二种接口的话不容易进行安全设计。

我现在的问题在于
1、第二种接口难道很难做分布式扩展么？我根据用户的id或者根据项目进行分布式的处理应该是可以的吧？在接口下面增加一层进行分发的话应该比较容易吧？

2、接口的设计应该是基于业务？还是基于灵活？比如第一种就是属于根据业务来，你前端有一个什么样的页面，我就给你返一个什么样的接口，但是这样的问题就是，接口不灵活，有100个页面就可能有100个接口，维护比较麻烦。
而第二种会比较灵活，我可能一个接口就返回N个类的数据，你前台需要什么，直接调用就行

3、关于安全设计我感觉，只要字符加密，增加校验，什么样的设计应该都行吧？

不知道大家现有的项目中，接口是怎么设计的！

[全栈极简]

从开发难度上来说，方案一比较清晰直观，有一个业务加一个接口，这是大多数情况下采用的方案。而方案二，会导致接口的逻辑过于复杂，开发的难度加大、后期的可维护性降低。而且由于是统一的接口，新增加的类型查询有可能会影响到之前的接口查询，所以发布之前要对之前所有的接口进行验证性测试，随着接口的复杂度上升，这个工作量是可想而知的。

[全栈极简]

跟安全性没有关系，方案二会对程序的可扩展性和验证性测试有一定要求。 一般情况下我建议采用方案一。

[bidisty]

这叫接口，你这设计我给不及格。 一个getQruery方法，全靠参数去区别。你这个设计文档我想没人看，参数太多了。 分拆业务，把你的需要分散在多个GET方法上去，能看懂好扩展，方便维护。 你从一开始就错了，所以二个方法都不好。 就例子来说，这个都是业务层的东西，实在是不方便显示层去直接访问。

[bcc222]

引用 10 楼 bidisty 的回复:

这叫接口，你这设计我给不及格。 一个getQruery方法，全靠参数去区别。你这个设计文档我想没人看，参数太多了。 分拆业务，把你的需要分散在多个GET方法上去，能看懂好扩展，方便维护。 你从一开始就错了，所以二个方法都不好。 就例子来说，这个都是业务层的东西，实在是不方便显示层去直接访问。

按照您的说法，是不是我可以这样理解： 接口就是单一原则，一个函数干一个事情，比如把typid变成 QueryWeight 、QueryHeight 等等 根据业务来，一个页面一个查询尽量返回所有的数据 但是这样搞的话，后台就要会有几百个接口，咋维护啊？

[bcc222]

如果要是分拆的太多的话，肯定后台的开发量比较多，并且有一个问题，写到N多的接口以后，很多接口之前的差别比较小，前后台的沟通成本会很高。

[wanghui0380]

我想你应该看那些公开的webapi，看看人家到底是怎么设计的 看看“淘宝api”，“京东api”，“微信api”，“百度地图api” 首先你要明白一点，作为api设计者，他并不知道你的页面到底要合成那些数据，所以那只能按业务逻辑去提供，除非前端经过测试那些零碎的api造成了瓶颈，才会去反过来通知api设计者，去照顾你，为你提供定制api 至于你说分拆太多，我们表示就算一个过100w的项目，标准业务api也不会超过50个，自己想把，50个接口，其中你一个相关功能，顶多使用其中的6，7个接口，这6，7个接口的组合是多少？？ 我们并不是要你根据页面当业务设计，我们实际说的是，他的逻辑上的业务。 比如你这个 逻辑上，个人信息是个资源对吧 逻辑上，常规体征指标是资源把 逻辑上，特殊单向指标是资源把（这个你可以考虑使用第2种方式，因为常规体征指标基本不会变化，特殊的生理，生化指标到会变） 话说我的确做过和你类似的东西，那项目是检验检疫的。类似体温，发烧，感冒，流鼻涕这种常规指标统一提供就好，类似什么病毒体判定，中东呼吸综合征这样特殊指标另外提供（这个提供可以采用你的第2种方式，我个人直接MEF插件组合）

[Justin-Liu]

我觉得你这根本就只有一种方式，而应该设计成你所谓的第二种，因为第一种欠缺思考。

[範先森]

我也觉得你的两种接口其实都是同一种啊，不过就是你的第一种，比较不细致的感觉，可以按照自己的业务需求，按第二种来实现，这样只要通过接口就能实现，想给他看什么就显示什么，而不需要过多的后台代码调整

[bcc222]

引用 4 楼 fxj805835819 的回复:

我也觉得你的两种接口其实都是同一种啊，不过就是你的第一种，比较不细致的感觉，可以按照自己的业务需求，按第二种来实现，这样只要通过接口就能实现，想给他看什么就显示什么，而不需要过多的后台代码调整

按照1楼的说法，如果我是第二种的话，如果想做单元测试，或者验证的话，会比较麻烦！不过我想的是做好参数验证（固定好参数类型）的话，应该问题也不大。 我的理解是，根据需求和表结构来看的，两种其实反映的是不同的思路和理念，跟我们设计表格的时候，我们考虑的是类似医院生化分析项目一样，用的是纵表，我们倾向于第二种，二我们后台设计思路是按照设备来的，项目都是横表，所以采用了第一种。

[bcc222]

引用 3 楼 FoxDave 的回复:

我觉得你这根本就只有一种方式，而应该设计成你所谓的第二种，因为第一种欠缺思考。

你这样一说的话，我仔细想想，的确挺像的，主要的区别还是在于返回的数据格式上！ 第一种也不是欠考虑，而是他们将前台的数据规定的太死了！后期接口数据会过多导致维护困难！

[wanghui0380]

个人并不纠结这个，因为restfull本身其实是viewmodel，他是和页面视图相关的。，其实和业务关系不大，比如说一个页面说要把3个没关系的东西放一个页面上显示，而且为了所谓的“效率”他让你给成一个接口，你做不做？？ 做啊，特殊定制就特殊定制呗。所以就webapi来说，他只是一些组合提供，所以关键是你得先把业务逻辑拆成原子，然后根据需要提供。 当然我个人使用第一种，第2种意外因素太多，因为你也没有限制人家，通常来说，我说如果前路不通，我会直接不给选择，也不会立个牌子说“前方有断崖，请小心通过”

[wanghui0380]

当然就第一种来说，我个人到也不会，开始就这样提供 最早的提供自然是业务最小项。 比如 ?个人基本信息 ?检查项 这样前端可以自由组合，当然实际使用上有时候前端会发现某些页面需要优化合并，他让他们自己提出优化合并的需求，我在特殊定制。

[正怒月神]

第一种， 虽然前台接口是3个，但是实际访问数据库，是同一个方法。所以对于后期修改来说，根本不存在所谓的维护困难。 区别只是在于返回的数据包装不同而已。

[範先森]

引用 5 楼 bcc222 的回复:

[quote=引用 4 楼 fxj805835819 的回复:] 我也觉得你的两种接口其实都是同一种啊，不过就是你的第一种，比较不细致的感觉，可以按照自己的业务需求，按第二种来实现，这样只要通过接口就能实现，想给他看什么就显示什么，而不需要过多的后台代码调整

按照1楼的说法，如果我是第二种的话，如果想做单元测试，或者验证的话，会比较麻烦！不过我想的是做好参数验证（固定好参数类型）的话，应该问题也不大。 我的理解是，根据需求和表结构来看的，两种其实反映的是不同的思路和理念，跟我们设计表格的时候，我们考虑的是类似医院生化分析项目一样，用的是纵表，我们倾向于第二种，二我们后台设计思路是按照设备来的，项目都是横表，所以采用了第一种。 [/quote] 其实不管是横表还是纵表，用户是不会来管的，设计思路肯定要清晰，你可以试着学习支付宝的支付接口来做，第一个感觉肯定是高大上，因为使用的时候肯定是你说怎么样怎么样用就可以了，尽管可能他们只用其中一个，但是，后期扩展性就好很多

[bcc222]

感谢各位讨论，我最终使用了，第二种，在使用的过程中的确诸如各位讨论的那样，虽然第二种比较好用，但是比较难控制，尤其是如果这个接口是对外使用或者是两个部门之间使用的话，就更难控制了，所以我这边的最终结论是：第一种比较好，但是看项目的大小以及合作情况来定！