Skip to content
This repository has been archived by the owner on Sep 14, 2019. It is now read-only.

Implement API endpoint for documentation retrieval #443

Open
arcrose opened this issue Apr 18, 2018 · 0 comments
Open

Implement API endpoint for documentation retrieval #443

arcrose opened this issue Apr 18, 2018 · 0 comments
Assignees
Labels
C-Feature Category: Issues containing feature requests that aren't modules D-Easy Difficulty: Issues that should be relatively easy to resolve E-Mentor Call for participation: Issues that have mentors available MIG-Client Component: Issues concerning the MIG clients P-Low Priority: Issues that can afford to be resolved when it is convenient to do so

Comments

@arcrose
Copy link
Contributor

arcrose commented Apr 18, 2018

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.

@arcrose arcrose added MIG-Client Component: Issues concerning the MIG clients C-Feature Category: Issues containing feature requests that aren't modules P-Low Priority: Issues that can afford to be resolved when it is convenient to do so D-Easy Difficulty: Issues that should be relatively easy to resolve E-Mentor Call for participation: Issues that have mentors available labels Apr 18, 2018
@arcrose arcrose added this to the MIG Client Daemon Phase 1 milestone Apr 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
C-Feature Category: Issues containing feature requests that aren't modules D-Easy Difficulty: Issues that should be relatively easy to resolve E-Mentor Call for participation: Issues that have mentors available MIG-Client Component: Issues concerning the MIG clients P-Low Priority: Issues that can afford to be resolved when it is convenient to do so
Projects
None yet
Development

No branches or pull requests

2 participants