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 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
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 ofAPIDocumentation
s, encoding that to JSON, and serving it to the user.