在具体编码以前我们根据前面的手绘原型,做以下两方面的基础工作: # 预期效果 ![](https://img.kancloud.cn/1f/de/1fde9a82465b0fc50cbeb15cf0a561e4_733x309.gif) ## ER图 ![](https://img.kancloud.cn/ec/6d/ec6d6bc7d3ed87a7975f7df3e62c212c_650x153.png) ## 定义接口 ``` POST /Student ``` #### 参数 Parameters | type | name | Description | Schema | | --- | --- | --- | --- | | **Body** | **学生** <br> *requried* | 学生信息 | Student | #### 返回值 Responses | HTTP Code | Description | Schema | | --- | --- | --- | | **201** | Created | 学生信息 | ##### 学生信息 | name | type | description | | --- | --- | --- | | name <br> *requried➊* | string(2-20)➋ | 学生名称 | | sno <br> *requried unique➌* | string(6) | 学号 | | klass <br> *requried* | {id: Long} | 班级 | * ➊ 增加了约束条件,即此项必须传入否则报错。 * ➋ 限制了长度范围,长度不符合要求将报错。 * ➌ 规定此项应该是唯一的,如果重复则报错。 是否对某些字段进行约束以及如何约束并没有定论,这更多的应该依据项目的实际情况。比如在我们的项目中通过调研我们确认:学生的名字最少为2个字符、最长的也不会超过20个字符;学号是唯一的,不存在两个学号重复的学生,而且必须唯一,同时其长度固定为6位;学生必须处于某个班级中,不存在没有设置班级的学生。依据上述调研信息,我们制定了更符合实现的传入规范,这将避免一些人为的非正常数据给我们系统带来的确定风险。在一定程度上规避了一些“在我这好好的”的“莫名”问题的产生。