-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(proposals): add nested API objects #639
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer option 1 as Vela has not released v1 yet, so, based on semantic versioning, API changes should be expected.
+ "owner": { | ||
+ "id": 1, | ||
+ "name": "OctoKitty", | ||
+ "favorites": ["github/octocat"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think favorites should be exposed in most cases. It seems to me that that's a user preference that the UI (or CLI) should be able to request for the current user, but nobody/nothing else needs it.
What purpose does exposing a user's favorites to a build (in env vars) or in these API calls have? Is there a use case I haven't considered?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we necessarily meant to propose that the owner
field has to have the favorites
displayed.
More so, I think we simply took the existing user API definition:
// User is the library representation of a user.
//
// swagger:model User
type User struct {
ID *int64 `json:"id,omitempty"`
Name *string `json:"name,omitempty"`
RefreshToken *string `json:"-"`
Token *string `json:"-"`
Hash *string `json:"-"`
Favorites *[]string `json:"favorites,omitempty"`
Active *bool `json:"active,omitempty"`
Admin *bool `json:"admin,omitempty"`
}
And removed the fields that can't be returned (-
in JSON field tags).
Regarding implementation, we can certainly ensure that favorites
is not returned to minimize payload size.
Here's an interesting approach to API compatibility guarantees:
https://www.vaultproject.io/api-docs We could copy that approach and add a note to the docs about compatibility. |
Per monthly review of open PRs, the Vela Admins will keep this proposal open until PRs are raised. |
gorm preload came in clutch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Co-authored-by: @ecrupper
Please vote for which option you prefer the most: