Exclude get, create, and update RPC Responses from rpc_allow_same_request_response Linter Rule

[Riku-programming]

Summary

I propose updating the rpc_allow_same_request_response linter rule to exclude get, create, and update RPCs from requiring separate response types.

This adjustment would align with the Google API Design Guide, which recommends returning the resource directly for these RPCs.

Details

The current rpc_allow_same_request_response rule mandates that all RPCs use distinct response messages, which is beneficial for flexibility in some cases. However, Google’s API Design Guide specifies that get, create, and update methods should directly return the resource object.

According to the buf document, this setting is enabled by default.
I understand that this linter is enabled when defining request messages, etc., but I think it is redundant that this linter also issues warnings for get, create, and update response messages.

Example

Currently:

// Warning: RPC response type "Book" should be named "GetBookResponse" 
rpc GetBook(GetBookRequest) returns (Book);

// Warning: Book used as the request or response type for multiple RPCs
rpc CreateBook(CreateBookRequest) returns (Book);
message GetBookResponse {
  Book book = 1;
}

message CreateBookResponse{ 
  Book book =1;
}

message Book{
  Book book =1;
}

Proposed Behavior(No Linter Warning)

// No warning in Linter
rpc GetBook(GetBookRequest) returns (Book);

// No warning in Linter
rpc CreateBook(CreateBookRequest) returns (Book);

I'd like to hear your opinions. Thanks for taking a look.

[bufdev]

We disagree with this approach, and disagree with the Google API Design Guide's position on this matter. Separate request and response types are important to make sure that the changes to one RPC do not guarantee changes to other RPCs (however, of course, types referenced by these request/responses may change and affect multiple RPCs).

[Riku-programming]

I see, so you don't agree with the Google API Design Guide either.
I understand your point of view. Thank you for explaining.