-
列表接口要注意是否要分页。尤其后台简单的CRUD页面尤其注意，不要偷懒省去分页参数。否则评审时其他人BB反而更浪费时间。
-
查询接口有id则尽量返回id。这个返回了前端老哥不会多BB的，因为很多页面需要跳转可以用到。 就算用不到也返回。
-
不同于上一点要返回某个字段，查询接口要少返回其他字段。特别是客户端接口多返回了一些字段，自己是想用于调试但前台用不到，返回了前台会迷惑且评审时候会多BB。我的解决方案是文档不写，但实际接口我还是返回下吧。
-
1个大"表单"(多个对象)的保存接口。要记得只要 传id即可，否则传了name等其他字段还要自己校验。
因为我数据库是存在Mongo了，1个大json都存下来了，所以"偷懒了"保存接口的传参示例也把整个json写上去了。
收获是: 肯定要参考数据库设计。但不要被数据库设计所绝对性影响接口设计。
-
接着上一点的收获。举例这个版本需求评审，我有个"安全告警承诺书"的对象需要前端传参。我数据库设计的是有个版本号字段，而id则用的Mongo的自带主键，没有特别指定1个id。
所以接口设计中我也写的是版本号。但是评审时候领导让我改成id。因为版本号那个是数据库的内容，前端不需要知道。
-
很多下拉选项id传错了都可以归为参数错误。确实也是，毕竟不是实际业务会提示的错误。否则前端还得根据我的错误码来提示，可是原型又没给出提示。
原因: 我是多次一举了，想把这个提示能复用到其他页面的。结果不仅这个页面不需要，其他页面也没有。
-
大的表单(对象)详情接口的设计，字段可以不平铺，改为多个对象的。
收获: 因为毕竟详情接口不是列表接口！
