Комментарии 7
Нельзя пропустить обязательные поля или использовать поля другого типа.
враньё. я могу не заполнять поля в запросе. и это будет корректно с т.з. proto. а вот null выставить явно нельзя. только тут про это ни слова.
Опять бесполезная реклама, может хватит спамить?
Protobuf имеет возможность заполнять не все поля. В версии 2 поля можно было помечать optional required в зависимости от требований. Более того это расширяемый формат, что означает, на более старом клиенте может не быть ещё новых полей и он будет корректен для сервера. Аналогично в обратную сторону, новые поля заполненные клиентом просто не будут отображаться на сервере(будут парситься но не иметь имени.
В версии 3 все поля опциональны, но при этом нет флага, а есть значения по умолчанию (насколько я помню). В версии 2 это было отдельным флагом
Так все же зачем использовать grpc вместо rest? Он так же не зависит от яп и определяет контракт
Статья пересказывает то, что не только можно прочитать в обзоре gRPC на одноименном сайте, но ещё и повторяет неоднократно опубликованное на Хабре. Я не нашел в ней вообще ничего нового.
Нет сравнительного профилирования gRPC с REST, protobuf с json, потоковой передачи с унарной, "хороших" данных для protobuf (небольших положительных чисел) и "плохих" (строк).
Не рассмотрены проблемы передачи не стандартизированных в protobuf типов данных. Например, decimal. А ведь gRPC позволяет использовать разные классы в разных языках для манипуляции такими типами, как объектами.
Тема optional вообще не раскрыта. А ведь без его указания в proto3 пропущенное число станет нулем, а вовсе не NULL.
О совместимости версий схем сказано только вскользь, тогда как в иерархических сообщениях подходы к обеспечению совместимости не всегда очевидны.
gRPC