Initial layout and refactor to more modular code #8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a proposal to address some of the code architecture and packaging suggestions. It introduces a client module that is the adapter between the HTTP and JSON world and the Go object/structs world.
Test layout is proposed using testify and httptest module which I have prior experience in.
This treatment has been applied to the "resources" sub-command as a demo
An outstanding question is with the JSON mode/pretty mode.
Do we need this?
If so, is this something that should be a formatting-only mode that marshals back from the client object layer?
Depending on 2, this may/may not apply. If we did want to show the underlying full JSON response, then I'd change some of the code architecture. Probably something like.
|-----------|/ /
| CLI | /
|-----------|\ /
\ |----------------|
---| Object Mapping |
| Client |
------------------
TABLE MODE
Personally, it's probably makes sense to do 2, but is there is value in this being a slightly smarter cURL (question 3)?