如何构建一个医院方接口
一、如何进行数据库建模
数据库建模一般需要使用工具PowerDesign，但是其实在navicat中是有类似的功能的
二、分析医院接口会有什么字段
其实很多的同学在入行的时候会有一个问题，没有设计思维。
表字段的设计方案
- 状态字段
- 启用/禁用
- 逻辑删除
- 并发的乐观锁字段
- 状态字段
- 说明字段（备注）
- 冗余字段
- 当我们的查询需要多张表进行联合查询的时候，并且某些表只用到了1-2个字段（后续的时候添加的）
- 关联字段
- 关联到某些表的时候，逻辑外键的关联
- 必备的业务字段
- 按需进行设计
- 约束设计（其他的设计方式）
- 非空
- 长度（合理的长度节省空间，并且我们可以校验数据的有效性）
- 合理的索引（散列度，散列度比较低的字段，不建议建立索引，也不建议做为条件查询）
- 列的不同值/列的总行数 电话号码 500W/500W = 1 散列度越趋近1 那么散列度越高 散列度趋近0，散列度越低
- 溯源字段（创建人，创建时间，修改时间）
- 创建人 账号的唯一标识
- 创建时间 记录第一次创建这条记录的时间
- 修改时间 最后一次修改的时间
三、根据需求确定项目字段
3.1 需求：预约平台需要跟医院内部的his交换签名，但是往往只需要单方面验签。
hospital_information
医院编号：平台分配，全局唯一 主键索引 id
医院名称 hospname
接口相关的调用密钥Key hospkey
api的基础调用路径 api_url
联系人 contacts
联系人的手机号 contacts_phone
状态字段（启用或者删除） is_disable
创建人 creater
创建时间 create_time
更新时间 update_time
逻辑删除字段 is_delete
四、编写接口
逆向工程 ------------------- 省略
1.mybatis-plus的条件构造器
编写接口之前，我们需要认识一下我们的mybatis-plus的条件构造器（Wrapper）
2.、AbstractWrapper
QueryWrapper(LambdaQueryWrapper) 和 UpdateWrapper(LambdaUpdateWrapper) 的父类
用于生成 sql 的 where 条件, entity 属性也用于生成 sql 的 where 条件
注意: entity 生成的 where 条件与 使用各个 api 生成的 where 条件没有任何关联行为
2.1、eq、allEq、ne、
eq：等于，参数一个条件
allEq：全等于，参数是一个map集合，可以一次匹配多个条件，
ne：不等于
2.2、gt、ge、lt、le
gt：大于，
ge：大于等于，
lt：小于，
le：小于等于
2.3、between、notBetween
between：在值1和值2之间，
notBetween：不在值1和值2之间
2.4、like、notLike、likeLeft、likeRight
like：’%值%’，
notLike：’%值%’，
likeLeft：’%值’，
likeRight：‘值%’
2.5、isNull、isNotNull
isNull：字段 IS NULL
isNotNull：字段 IS NOT NULL
2.6、in、notIn
in：字段 IN (v0, v1, …)，
notIn：字段 NOT IN (value.get(0), value.get(1), …)
2.7、inSql、notInSql
inSql：字段 IN ( sql语句 )，
notInSql：字段 NOT IN ( sql语句 )
2.8、or、and
or：拼接 OR，
and 嵌套
注意事项:
主动调用or表示紧接着下一个方法不是用and连接!(不调用or则默认为使用and
2.9、exists、notExists
exists：拼接 EXISTS ( sql语句 )，
notExists：拼接 NOT EXISTS ( sql语句 )
2.10、orderBy、orderByAsc、orderByDesc
orderBy：指定是否排序，升序还是降序
orderByAsc：排序：ORDER BY 字段, … ASC，
orderByDesc：排序：ORDER BY 字段, … DESC
3.QueryWrapper
说明:继承自 AbstractWrapper ,自身的内部属性 entity 也用于生成 where 条件
及 LambdaQueryWrapper, 可以通过 new QueryWrapper().lambda() 方法获取
4、UpdateWrapper
说明:继承自 AbstractWrapper ,自身的内部属性 entity 也用于生成 where 条件及 LambdaUpdateWrapper, 可以通过 new UpdateWrapper().lambda() 方法获取!
5. LambdaQueryWrapper
利用lambda表达式的一个用法（类::静态方法）获得属性对应自带你们，可防止写错字段名
6. LambdaUpdateWrapper
利用lambda表达式的一个用法（类::静态方法）获得属性对应自带你们，可防止写错字段名
跨域问题：
一、为什么会跨域
说到跨域不得不谈的就是浏览器的同源策略，跨域也是因为浏览器这个机制引起的，这个机制的存在还是在于安全。所谓的“同源策略”，最早是由 Netscape公司提出的一个安全策略，后来这就成为了浏览器最核心也最基本的安全功能，现在所有支持 JavaScript 的浏览器都会使用这个策略。
举例：举例来说，http://www.mashibing.com/index.html，这个网址，http是协议，www.mashibing.com是域名，80是端口号(80端口号默认可以省略)。
二、什么是源
Web内容的源由用于访问它的URL 的方案(协议)，主机(域名)和端口定义。只有当方案，主机和端口都匹配时，两个对象具有相同的起源。
同源不同源一句话就可以判断：就是url中 scheme host port 都相同即为同源
三、同源不同源举例
同源策略的具体规则如下表所示：
举例：
四、浏览器为什么需要同源策略
同源策略是一个重要的安全策略，它用于限制一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。
五、常规前端请求跨域
在没有前后端分离的时候，跨域问题往往是很少的。因为前后端都部署到一起。现在前后端分离不管vue /react 面临跨域请求的问题。
1.
2.利用JSONP
- 底层利用script实现，发送请求的传递callback的参数；
- 服务端可以到这个参数，给这个参数加上一个()然后直接返回给浏览器；
- 浏览器接收到返回的内容后就会解析成一个js的函数调用，前提先要定义这个函数。
也就是说 其实也是利用
JSONP安全性问题：
1.脚本注入攻击
2.恶意域名—跨站脚本攻击
3.数据泄漏
后端解决的方式
- @CrossOrigin：在响应头中添加一个地址；
- 在SpringMVC的配置文件中进行配置。
<mvc:cors><mvc:mapping path="/**" allowed-origins="*"allowed-methods="POST, GET, OPTIONS, DELETE, PUT,PATCH"allowed-headers="Content-Type, Access-Control-Allow-Headers, Authorization, X-Requested-With"allow-credentials="true"/>
</mvc:cors>
