Dependent on #442.
Ideally, what we'd like (to start) are data structures representing the request and response data types for each of the endpoints we'll support. Each structure may implement some interface to provide self-documentation that can be aggregated and served as JSON.
The following example sketches this approach:
type SelfDocumenting interface {
Documentation() APIDocumentation
}
type APIDocumentation struct {
Method string `json:"method"`
Route string `json:"route"`
// ...
}
type ReqActionStatus struct {
ActionID string
}
func (req ReqActionStatus) Documentation() APIDocumentation {
return APIDocumentation {
Method: "GET",
Route: "/v1/actions/:id/status",
// ...
}
}
The above could be expanded upon to include something like an Endpoint struct containing empty instances of a request and response type, so that we can start composing these structs to get complete documentation for each endpoint. Serving this information would then simply be a matter of constructing a big nested collection of APIDocumentations, encoding that to JSON, and serving it to the user.
Dependent on #442.
Ideally, what we'd like (to start) are data structures representing the request and response data types for each of the endpoints we'll support. Each structure may implement some interface to provide self-documentation that can be aggregated and served as JSON.
The following example sketches this approach:
The above could be expanded upon to include something like an
Endpointstruct containing empty instances of a request and response type, so that we can start composing these structs to get complete documentation for each endpoint. Serving this information would then simply be a matter of constructing a big nested collection ofAPIDocumentations, encoding that to JSON, and serving it to the user.