请教一下,现在可以做到在swagger接口页面全局设置header头的鉴权字段么

删除

分享规范化路由学习笔记

强哥，自动生成的 swagger 页面中，【Responses】栏只列出了 200 状态。

[假装有截图]

是否有办法能自定义每个路由的 400、401、403、500 错误呢？

或者为所有路由配置统一的 400、401、403、500 错误。

http://gf.l11.cn/   规范化路由代码生成

gf 工具里面应该集成这个功能,模板能定义最好,起码把该有的文件给创建了.哈哈

swagger ui在使用gf-user-demo时,没有try it out按钮哦

关于goframe2.0规范路由的个人见解

使用v2.0.1版本及以上版本会发现 swaggerUI被修改了为 redoc了。redoc缺少了 Try it console。能不能提供一个方式，可以选择swaggerUI或者redoc 么？

灵活性太受限了

     比如一个接口，可能有多个路由，但入参结构体相同，应如何处理呢？

如果希望自定义response 该如何处理，比如 code 为 string 类型，

不同的分组路由，使用不一样的response。   历史遗留系统，返回样式五花八门

请教一下，新版本的路由注册，我有点迷，普通的用法我会

比如我发送 GET 和 PUT 请求，是 user/:id ，那么 g.Meta 里面的 path 标签应该如何写呢？

如果我打算把参数放在路径里面，不通过 struct 里面的其它属性来定义，我该如何在控制器中获取到这个 :id 呢？

我用了 

g.RequestFromCtx(ctx).Get("id")

好像获取不到

可能我的理解级别不够，分组路由不挺好吗，为什么非要卷出一个规范路由，这所谓的规范，反正让我背这一串字符串，挺难，接口上百个，感觉这字符串难维护，比如：`path:"/user/{uuid}" method:"put" `

对于这种规范路由的方式，如果返回的格式不同，是不是就不能用了？比如想下面两种格式。如果能用的话，统一返回值处理那里应该怎么做？

{
	"code": 200,
	"message": "success"
	"data":{
		"id":1
	}
}

{
	"code": 200,
	"message": "success"
	"data":[
		{"id":1},
		{"id":2},
		]
	"total":2
}

请教一下，请求结构体中的参数从 http header 获取参数的情况，使用 in:"header" 是否可以直接获取值。

我本地测试发现不行，不知是框架暂时不支持还是我使用姿势不正确，望可以解答。谢谢。

type GetUserInfoReq struct {
   g.Meta        `tags:"用户" sm:"获取用户信息"`
   Authorization string `json:"Authorization" dc:"用户token" in:"header"`
}

两个问题

1.  如下，如果一个路由需要两种请求方式怎么解，我要在conteoller里创建两个 结构体以及函数吗
2. 我在声明中注入了我自己的tag 比如 auth 我怎么取值

type RoleUpdateReq struct {
	g.Meta `path:"/backend/role" tags:"三体" method:"get/post" auth:"true"`
}

原谅我吐槽一下，这个api结构体的字段tag都有哪些，从截图里我看到了dc是字段描述，好歹文档提一嘴吧

我想出一个前台接口文档，一个后台接口文档，同一个项目，应该怎么弄

有一个问题， 设置参数 in：query 但是还是从请求体里获取的 那设置这个的必要性在哪呢，这个并不是从query取得值

规范路由下预检OPTIONS请求怎么通过；

规范路由只定义了post方法；

发起预检请求直接返回404 not found了，没有进到cors中间件

请问密文请求，解密后如何按现在的规范传入这种结构呢

func (c *cHello) Hello(ctx context.Context, req *apiv1.HelloReq) (res *apiv1.HelloRes, err error) {
	g.RequestFromCtx(ctx).Response.Writeln("Hello World!")
	return
}

这种绑定形式，只是内容获取需要先解密，解密后才能拿到json字符串

s.Group("/", func(group *ghttp.RouterGroup) {
		group.Bind(
            new(Hello),
        )
	})

一个接口应当只做一件事情，HTTP Method是有意义的，一个接口支持多种HTTP Method方式是接口设计不合理，在规范路由下不支持。建议重新审视接口设计。

以上说法岂不是说Restful的设计有问题吗？为啥说一个接口支持多种`http Method`方式时不合理的呢？

同样的疑问： 一个接口应当只做一件事情，HTTP Method是有意义的，一个接口支持多种HTTP Method方式是接口设计不合理，在规范路由下不支持REST 风格？

有个比较别扭的是规范路由在controller中时如何判断请求参数是否存在？比如，获取用户列表接口 /user/list ，现在加一个星标用户的筛选（即：（1）返回无论有无星标的所有用户：/user/list，（2）返回无星标用户：/user/list?star=0，（3）返回有星标用户：/user/list?star=1）。由于golang的基本类型没有空值的定义，无论将star定义为bool还是int，在controller中读取到star为0时，无法分辨是否是golang的默认值，也就分辨不出是第一还是第二种情况。再调用ghttp.Request来判断的话感觉失去使用规范路由的意义和便利性。我现在临时做法是把无星标的请求设为/user/list?star=2，然后在向数据库请求时候需要在controller再转换一次，太麻烦。

这个问题在字符串类型参数中也存在，无法分辨是真的空字符串还是前端没有传这个参数