大型医疗挂号微服务“马上好医”医疗项目（4）设计一个医院方接口

如何构建一个医院方接口

一、如何进行数据库建模

数据库建模一般需要使用工具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 面临跨域请求的问题。

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>