Может ли изменение типа сообщения на аналогичное нарушить обратную совместимость? - PullRequest
Новая
       33

Может ли изменение типа сообщения на аналогичное нарушить обратную совместимость?

0 голосов
/ 03 мая 2019

Я хочу сохранить свое приложение от будущих проблем с обратной совместимостью.Теперь у меня есть эта версия test.proto: 

syntax = "proto3";

service TestApi {
    rpc DeleteFoo(DeleteFooIn) returns (BoolResult) {}
    rpc DeleteBar(DeleteBarIn) returns (BoolResult) {}
}

message DeleteFooIn {
    int32 id = 1;
}

message DeleteBarIn {
    int32 id = 1;
}

message BoolResult {
    bool result = 1;
}

Меня интересует случай, когда я захочу изменить сообщение результата DeleteBar() на сообщение типа «DeleteBarOut»: 

syntax = "proto3";

service TestApi {
    rpc DeleteFoo(DeleteFooIn) returns (BoolResult) {}
    rpc DeleteBar(DeleteBarIn) returns (DeleteBarOut) {}
}

message DeleteFooIn {
    int32 id = 1;
}

message DeleteBarIn {
    int32 id = 1;
}

message DeleteBarOut {
    reserved 1;
    string time = 2;
}

message BoolResult {
    bool result = 1;
}

Вопрос о обратной совместимости по проводам со старым .proto.Могу ли я изменить имя сообщения с «BoolResult» на «DeleteBarOut»?

Или мне следует сохранить старое имя сообщения и отредактировать список полей «BoolResult»?Но тогда как я могу сохранить DeleteFoo() от любых изменений в этом решении?

1 Ответ

0 голосов
/ 03 мая 2019

При внесении критических изменений в API, подобный этому, обычной практикой является поддержка обеих версий при переходе.Для этого вам необходимо добавить поле version к сообщению запроса, а затем в обработчике запроса направить сообщение в разные бэкэнды в зависимости от того, какая версия указана.Если больше нет трафика, идущего к бэкэнду v1, вы можете жестко переключиться на v2 и прекратить поддерживать v1.

К сожалению, если вы просто измените определение RPC без управления версиями, невозможно избежать несовместимости версиймежду сервером и клиентом.Другой вариант, конечно, это добавить новую конечную точку RPC, а не модифицировать существующую.

В общем, если вы вносите критические изменения в API, у вас будет неприятное время.

...