Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add
json:""
marshaling annotations to response structs (#21)
## Problem There's been some UX feedback regarding marshaling of some of our response structs. Primarily, we're not using `json:"key_name"` annotation for our struct fields so they default to capitalized keys in JSON output when marshaled. IE: `{ "Usage": { "ReadUnits": 5 }}`. We'd like these lower case and matched with our API spec. There are also instances where we're returning pointers for certain `*int32` fields which can be irritating to consumers needing to dereference and nil-check. In certain cases we can default any nil pointer values to 0 before returning things. There's no testing for the marshaling on any of our custom structs. ## Solution I may have gone a bit overboard with the testing here. The bulk of this is tests and the tests are all very similar, definitely open to opinions on removing if people find them unnecessary, but changing up how the JSON is produced is pretty easy and it's an important point of integration in my mind, so maybe worth testing for. I also wasn't clear if adding these annotations to our request structs made sense either, so I left those out for now. Overall I'm still working on getting a better understanding of Go syntax and expectations. - Add JSON marshaling annotations to the response structs in `models.go` and `index_connection.go`. - Update `Collection` and `Usage` structs to default integer values rather than using pointers. - Add new `models_test.go` file to run through some validation on struct marshaling, also add unit tests to `index_connection_test.go`. Originally I thought `omitempty` for some of these pointers may be helpful from a consumer standpoint, but I'm actually not sure the more I've thought about it. Does it make sense to omit more or less things? Other feedback here would be much appreciated. ## Type of Change - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds functionality) - [X] Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] This change requires a documentation update - [ ] Infrastructure change (CI configs, etc) - [ ] Non-code change (docs, etc) - [ ] None of the above: (explain here) ## Test Plan Unit tests to explicitly stress marshaling the structs via `json.Marshal()`.
- Loading branch information