Skip to content
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

fix: do not return repeated directly #1605

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sago2k8
Copy link
Contributor

@sago2k8 sago2k8 commented Jan 31, 2025

Use the complete response when the response is a list.

for some method the example does not match the actual response and we probably want to ensure the response is not nested. maybe the question is around breaking the API, so happy to do it for V1

Use the complete response when the response is a list

Signed-off-by: Santiago Jimenez Giraldo <[email protected]>
Copy link

The latest Buf updates on your PR. Results from workflow Buf CI / push-module (pull_request).

BuildFormatLintBreakingUpdated (UTC)
✅ passed✅ passed✅ passed✅ passedJan 31, 2025, 3:51 PM

@bojand
Copy link
Member

bojand commented Jan 31, 2025

Generally I agree with this. See https://google.aip.dev/132.
We have a few instances of similar issue in CloudStorageService service, List* methods return the actual list and not the object containing the list.
I am not sure if we should just update existing API. Probably not safe for breaking existing functionality. But yes we should fix this for v1.

get: "/v1alpha2/topics/{topic_name}/configurations"
response_body: "configurations"
};
option (google.api.http) = {get: "/v1alpha2/topics/{topic_name}/configurations"};
Copy link
Contributor

@weeco weeco Feb 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do it, despite knowing the number of entries is very limited and will never exceed an unreasonable number that couldn't be retrieved in one go? The AIP-132 seems to suggest that. I guess we'll follow then

@@ -292,10 +292,7 @@ service TopicService {
};
}
rpc GetTopicConfigurations(GetTopicConfigurationsRequest) returns (GetTopicConfigurationsResponse) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if we also need to rename this from Get to List accordingly @sago2k8 @bojand . One could argue for both cases. It could be argued as one resource (the configuration of a topic which happens to have several properties) or a list of resources (configurations for topics)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good observation. Maybe ListTopicConfigurations() is a better choice. Agree it kinda depends on how you look at it. But I do not feel strongly about it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants