Controller
为每个页面单独写一个Controller，完全不必遵循Restful风格。
为每一个请求单独写一个方法，放弃后端接口复用。这样做有以下几点原因
- 业务上无法保证各个下拉框的取值范围一致。例如班级类型，也许在新增订单时班级类型有【普通班】和【寒假班】，但是作为查询条件时有【普通班】，【寒假班】和【暑假班】。另外作为转班时，可能下拉框有除了现在班级外其他班级，这个需要根据当前id来确定
- 权限范围不一样，如果两个页面复用了后面同一个接口，特别是下拉框这种在多个页面上复用的接口，如果不知道是从哪个页面调用过来将导致无法鉴权
- id的处理
- 无id，这样通过url就可以查询到对应的后端方法，但是会损失信息，另外不利于下面会提到的无session鉴权。
- id放入url中，这个是restful风格的做法
- id放在url结尾，这个是我觉得最佳的做法。有id方便做数据权限控制。id位置固定，方便后面做方法映射。
- 下拉框中id的处理：不放入url因为这个可以做有session鉴权（也需要），另外也适应多选的情况
ViewObject
可以作为Controller的内部类，因为这个VO是专属的，其他Controller根本不可能用到。
因为vo在interface里，所以自动是public static的。
但是不同的vo的名字还是不要重复了，否则需要swagger的时候不能正确的生成文档。
另外ViewObject是class或者interface貌似都可以，反正也不用管理调用方反序列化的问题。
Implements
也不用ControllerImpl结尾，这样生成的文档更短，更简洁。
Enum
理论上api应该不用管实现的。但是这个api是专属的，只有一个实现。可以考虑使用enum，这样方便调用方（特别是通过swagger时）来准确的传入参数。
Data
列表页
基本上来自Database，遵循以下原则
- schema的名字和项目名字一致
- table名字和页面的名字一致（特别是列表页）
- 列名和前端列表页的表头一致，至于筛选项是否可以不一致呢？（特别是这一列已经在表头里有的情况下）
下拉框
这种查询不复杂，可以考虑使用redis，使用hash这种数据类型
总结
无文档化
来源：CSDN
作者：首席IT民工
链接：https://blog.csdn.net/u012220365/article/details/103626686