注解 | 描述 |
---|---|
@Summary | 摘要 |
@Produce | API 可以产生的 MIME 类型的列表,MIME 类型你可以简单的理解为响应类型,例如:json、xml、html 等等 |
@Param | 参数格式,从左到右分别为:参数名、入参类型、数据类型、是否必填、注释 |
@Success | 响应成功,从左到右分别为:状态码、参数类型、数据类型、注释 |
@Failure | 响应失败,从左到右分别为:状态码、参数类型、数据类型、注释 |
@Router | 路由,从左到右分别为:路由地址,HTTP 方法 |
安装:
go get -u github.com/go-playground/validator/v10
标签 | 描述 |
---|---|
required | 必填 |
gt | 大于 |
gte | 大于等于 |
lt | 小于 |
lte | 小于等于 |
min | 最小值 |
max | 最大值 |
oneof | 参数集内的其中之一 |
len | 长度要求与 len 给定的一致 |
UploadSavePath:上传文件的最终保存目录。
UploadServerUrl:上传文件后的用于展示的文件服务地址。
UploadImageMaxSize:上传文件所允许的最大空间大小(MB)。
UploadImageAllowExts:上传文件所允许的文件后缀。
在实际项目中,应当将应用服务和文件服务给拆分开来,因为从安全角度来讲,文件资源不应当与应用资源摆放在一起,否则会有风险,又或是直接采用市面上的 OSS 也是可以的。
市场上比较常见的两种 API 访问控制方案,分别是 OAuth 2.0 和 JWT,但实际上这两者并不能直接的进行对比, 因为它们是两个完全不同的东西,对应的应用场景也不一样,我们可以先大致了解,如下:
- OAuth 2.0:本质上是一个授权的行业标准协议,提供了一整套的授权机制的指导标准,常用于使用第三方登陆的情况,像是你在网站登录时,会有提供其它第三方站点(例如用微信、QQ、Github 账号)关联登陆的,往往就是用 OAuth 2.0 的标准去实现的。并且 OAuth 2.0 会相对重一些,常常还会授予第三方应用去获取到我们对应账号的个人基本信息等等。
- JWT:与 OAuth 2.0 完全不同,它常用于前后端分离的情况,能够非常便捷的给 API 接口提供安全鉴权,因此在本章节我们采用的就是 JWT 的方式,来实现我们的 API 访问控制功能。
docker run -d --name jaeger \
-e COLLECTOR_ZIPKIN_HTTP_PORT=9411 \
-p 5775:5775/udp \
-p 6831:6831/udp \
-p 6832:6832/udp \
-p 5778:5778 \
-p 16686:16686 \
-p 14268:14268 \
-p 9411:9411 \
jaegertracing/all-in-one:1.16