Support httpin tags for automatically generating params from structs.

[hookenz]

Is your feature request related to a problem? Please describe.
Keeping documentation up to date is always difficult. Devs add new params and forget to update the swag comments so it gets missed and docs are outdated. Docs are a big maintenance overhead and mistakes cost a lot of time and money to resolve. Automation is key.

Describe the solution you'd like
httpin is a tool that decodes http requests into structs.
http uses go struct tags to help with the decoding process.

Swag already parses the structs for example tags. If we could also add support for httpin tags then we would just need to supply the appropriate object to the docs and swag can figure out the rest. This means as we change the structs, the generated docs automatically reflect the changes.

https://ggicci.github.io/httpin/

Describe alternatives you've considered
Not using swag but generating server based on code. However our codebase is too big and complex to switch.
This addition would solve a lot of issues for us and I think it'd be an amazing feature.

Additional context
none

[manicar2093]

Hi! I was looking for the same feature and this was requested before: #248

This feature could be amazing. Swag is already cool, but generate params from structs would level up the tool.

In this issue #248 there is an example of how this could be decleared in structs:

type GetProductParams struct {
	XAPICountry *string `swag:"X-API-Country,header"`
	XAcceptVersion *string `swag:"X-Accept-Version,header"`
        SomeParam *string `swag:"some_param,query"`
        SomeParam2 *string `swag:"some_param2,query"`

	timeout    time.Duration
	Context    context.Context
	HTTPClient *http.Client
}

I will check the code to see if I can create a MR for this, but if anyone could tell me where I could start would be fine 😺

[tanenbaum]

Likewise, for Gin operations, it would be a very useful feature.

In that particular case, it's not always explicit just from the struct tags where the values will come from, e.g. the form tag name is used for both query string GET parameters and form data in a POST request.

It might be nice to have something like:

// @StructParams     query       QueryArgsStruct
// @StructParams     formData    FormDataStruct

So it behave similarly to the way @Params works except all the other metedata is pulled from the struct.