- do not support query and form definitions, use parameters instead.
**How to use?**
Use the `useDefinitions` keyword in the info code block of the API file to declare the enable. This value is a boolean value. When set to `true`, it will enable the generation of definitions. Otherwise, it will be generated according to properties, and the default is `false`, for example:
```go
syntax = "v1"
info (
...
wrapCodeMsg: true
useDefinitions: true
)
...
```
the demo result of swagger.json
```json
{
...
"responses": {
"200": {
"description": "",
"schema": {
"type": "object",
"properties": {
"code": {
"description": "1001-User not login\u003cbr\u003e1002-User permission denied",
"type": "integer",
"example": 0
},
"data": {
"$ref": "#/definitions/FormResp"
},
"msg": {
"description": "business message",
"type": "string",
"example": "ok"
}
}
}
}
}
...
}
```
For a complete API example, please refer to the `api/swagger/example/example.api` file in pr. For a complete swagger result example, please refer to the `api/swagger/example/example.swagger.json` file in pr.
## 2. `goctl api go` code generation
- [bug-fix] Add flag `--type-group` to control the output of types(deprecated: experimental switch control type grouping is no longer used), if true, the types in only one group will separate by file.
- example `goctl api go --api demo.api --dir demo --type-group`
- use `group` keyword in @server block to define the group name in api file, for example
```go
@server(
group: user
)
service demo{
...
}
```
the example of separated types by file
```
.
└── types
├── common.go
├── gotoolexport.go
├── importfile.go
├── process.go
└── types.go
```
## 3 API Parser
- supported identifier value for info key-value in api parser
