Based on the work from https://github.com/yvasiyarov/swagger
It uses a similar approach but with expanded annotations and it produces a swagger 2.0 spec.
The goal of the syntax is to make it look as a natural part of the documentation for the application code.
The generator is passed a base path (defaults to current) and tries to extract a go package path from that. Once it has a go package path it will scan the package recursively, skipping the Godeps, files ending in test.go and directories that start with an underscore, it also skips file system entries that start with a dot.
Once the parser has encountered a comment that matches on of its known tags, the parser will assume that the rest of the comment block is for swagger.
Annotation | Format |
---|---|
Description | free text block or a url containing the description for this API |
Title | the short description for the API |
TOS | allows for either a url or a free text definition describing the terms of services for the API |
Version | the current version of the API |
Contact | the name of for the person to contact concerning the API eg. John Doe <john@blogs.com> http://john.blogs.com |
License | the name of the license followed by the URL of the license eg. MIT http://opensource.org/license/MIT |
The description property uses the rest of the comment block as description for the api when not explictily provided
Annotation | Format |
---|---|
Swagger | the swagger version to use for this API, defaults to latest known (currently 2.0) |
14 Nov 2015