Comments 6
Честно, не понял пункта с сравнением SOAP и REST в моменте передачи данных.
Якобы в SOAP стандартизированные данные, а в REST нет.
В контексте REST указан тип данных JSON, который тоже имеет некую согласованную форму представления. Чем же это является тогда, если не стандартом?
UPD
SOAP также может использоваться в REST архитектуре, но не используется лишь из-за объема передаваемой информации.
Написали, что такое gRPC, но не написали, что такое protobuf
Позволю себе тоже придраться к некоторым моментам по тексту:
В gRPC один компонент, клиент, вызывает определенные функции в другом программном компоненте — сервере. При этом программная реализация клиента и сервера не имеет особого значения благодаря кроссплатформенности протокола gRPC.
Программная реализация и в REST не имеет значения. Это следует из самого архитектурного подхода.
В примере описания библиотеки я постаралась собрать самые часто встречающиеся (хорошие и не очень) паттерны реализации контрактов.
На официальном сайте Protobuf есть основные рекомендации https://protobuf.dev/programming-guides/dos-donts/ - можно было бы добавить в статью.
Proto сильно облегчает жизнь разработчикам сервиса, для которого пишется контракт. Если меняется ответ, сервис узнает об этом сразу, а не когда обновят документацию (если обновят). Сваггер всем писать всегда лень.
Непонятно, что значит "сервис узнаёт". Имеет в виду, что разработчики сервисов-потребителей сразу видят изменения в proto-файле другого сервиса? Необходимость в спецификации это не отменяет.
REST API
Нет документирования и стандартизации.
Нет стандарта использования кодов ответов, поэтому часто в успешных кодах могут передаваться ошибки.
Почему же нет? Де-факто Swagger / OpenAPI и есть стандарт к документированию.
А HTTP-коды описаны в стандарте https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes.
gRPC
Контракт: обязательно пишется по стандарту Protocol Buffers, компилируется внутренним компилятором protoc, который генерирует необходимый исходный код классов из определений в proto-файле.
Стандартизация кодов ошибок, зашитая в protobuf.
Строго говоря, gRPC можно использовать с другими форматами передачи данных, например https://grpc.io/blog/grpc-with-json/
С ошибками в gRPC ситуация не лучше, чем в REST: да, есть типовые коды ошибок, но в практике от них мало пользы - приходится расширять собственными, опираясь, например, на разработки Google https://cloud.google.com/apis/design/errors#error_model
Привет. Постараюсь ответить на весь коммент кусочками:
Программная реализация и в REST не имеет значения. Это следует из самого архитектурного подхода.
Как я писала во введении, статья призвана познакомить системных аналитиков с протоколом и провести некую "обзорную экскурсию". Для человека, который с протоколом работал, этот момент очевиден. Но при первом знакомстве, как мне кажется, этот момент стоит упомянуть
На официальном сайте Protobuf есть основные рекомендации https://protobuf.dev/programming-guides/dos-donts/ - можно было бы добавить в статью.
Да, пожалуй, стоило указать среди источников. Но для обзора я постаралась вынести самые важные из этих пунктов просто и доступно. Плюс добавить личного опыта (почему, например, разработчики просят избегать oneof)
Непонятно, что значит "сервис узнаёт". Имеет в виду, что разработчики сервисов-потребителей сразу видят изменения в proto-файле другого сервиса? Необходимость в спецификации это не отменяет.
Да, очень крутая и удобная особенность прото - самодокументируемость. Конечно, это не отменяет спецификации, речь была совсем не о том. Давайте будем честны, не всегда спецификация есть и не всегда она актуальна. Тем более, если апи разрабатывает другая команда/компания/оно публичное - нет никаких гарантий, что дока актуальна. С прото контрактами такого нет. Могут быть проблемы с пониманием, как именно использовать методы, но это уже немного другой разговор.
Почему же нет? Де-факто Swagger / OpenAPI и есть стандарт к документированию.
и
Строго говоря, gRPC можно использовать с другими форматами передачи данных, например https://grpc.io/blog/grpc-with-json/
Эту тему уже затронули в комменте выше, но повторюсь: JSON у REST не является стандартом хотя бы потому, что его использование не является обязательным. Это самый популярный вариант и многие даже не слышали об альтернативах, но все-таки де-юре не стандарт. Слышала о JSON в gRPC, но особо примеров применения не нашла. Здесь на хабре пишут, что это расширение является очень медленным и мало применимым.
А HTTP-коды описаны в стандарте https://www.rfc-editor.org/rfc/rfc9110.html#name-status-codes.
и
С ошибками в gRPC ситуация не лучше, чем в REST: да, есть типовые коды ошибок, но в практике от них мало пользы - приходится расширять собственными, опираясь, например, на разработки Google https://cloud.google.com/apis/design/errors#error_model
Здесь речь скорее о том, что получая ошибку в gRPC, ты получаешь некий числовой и текстовый код ошибки. А в REST в 200 коде (когда уже все, вроде бы, успешно прошло) может где-нибудь в теле приходить еще массив ошибок. Разработчики в этом случае рассуждают примерно так: запрос отработал, значит 200 код, но с данными что-то не то, поэтому вот в теле будет дополнительная ошибка. И, если сваггер неактуальный, как это отловить? Под "нет стандарта использования кодов" я имела ввиду именно эту ситуацию. Один сделает, условно, 3 кода ответа (200, 401, 500), но в 200 положит в тело еще 20 вариантов ошибки. А другой сделает числовой код на каждый случай. И со своей логикой каждый будет прав. А другим потом с этим как-то надо взаимодействовать. Именно в этом, на мой взгляд, состоит недостаток "нет стандарта использования кодов"
Что нужно знать о gRPC системному аналитику