Согласна, но единственное для меня коммент как будто про диагональ 7+.
Сама пользуюсь PocketBook 632 plus (у нее 6"), для меня идеальный вариант - компактная, E-Ink с подсветкой, долго держит заряд. Поначалу переживала, что не хватит памяти (карты нет), но вместилась довольно большая библиотека. PDF на такой диагонали удобно читать не всякий: с текстовыми с малым количеством иллюстраций никакой разницы с fb2, например, а вот какие-нибудь эл схемы я бы предпочла рассматривать на экране побольше, думаю, планшет был бы оптимален.
Привет. Постараюсь ответить на весь коммент кусочками:
Программная реализация и в REST не имеет значения. Это следует из самого архитектурного подхода.
Как я писала во введении, статья призвана познакомить системных аналитиков с протоколом и провести некую "обзорную экскурсию". Для человека, который с протоколом работал, этот момент очевиден. Но при первом знакомстве, как мне кажется, этот момент стоит упомянуть
Да, пожалуй, стоило указать среди источников. Но для обзора я постаралась вынести самые важные из этих пунктов просто и доступно. Плюс добавить личного опыта (почему, например, разработчики просят избегать oneof)
Непонятно, что значит "сервис узнаёт". Имеет в виду, что разработчики сервисов-потребителей сразу видят изменения в proto-файле другого сервиса? Необходимость в спецификации это не отменяет.
Да, очень крутая и удобная особенность прото - самодокументируемость. Конечно, это не отменяет спецификации, речь была совсем не о том. Давайте будем честны, не всегда спецификация есть и не всегда она актуальна. Тем более, если апи разрабатывает другая команда/компания/оно публичное - нет никаких гарантий, что дока актуальна. С прото контрактами такого нет. Могут быть проблемы с пониманием, как именно использовать методы, но это уже немного другой разговор.
Почему же нет? Де-факто Swagger / OpenAPI и есть стандарт к документированию.
Эту тему уже затронули в комменте выше, но повторюсь: JSON у REST не является стандартом хотя бы потому, что его использование не является обязательным. Это самый популярный вариант и многие даже не слышали об альтернативах, но все-таки де-юре не стандарт. Слышала о JSON в gRPC, но особо примеров применения не нашла. Здесь на хабре пишут, что это расширение является очень медленным и мало применимым.
С ошибками в gRPC ситуация не лучше, чем в REST: да, есть типовые коды ошибок, но в практике от них мало пользы - приходится расширять собственными, опираясь, например, на разработки Google https://cloud.google.com/apis/design/errors#error_model
Здесь речь скорее о том, что получая ошибку в gRPC, ты получаешь некий числовой и текстовый код ошибки. А в REST в 200 коде (когда уже все, вроде бы, успешно прошло) может где-нибудь в теле приходить еще массив ошибок. Разработчики в этом случае рассуждают примерно так: запрос отработал, значит 200 код, но с данными что-то не то, поэтому вот в теле будет дополнительная ошибка. И, если сваггер неактуальный, как это отловить? Под "нет стандарта использования кодов" я имела ввиду именно эту ситуацию. Один сделает, условно, 3 кода ответа (200, 401, 500), но в 200 положит в тело еще 20 вариантов ошибки. А другой сделает числовой код на каждый случай. И со своей логикой каждый будет прав. А другим потом с этим как-то надо взаимодействовать. Именно в этом, на мой взгляд, состоит недостаток "нет стандарта использования кодов"
Речь о том, какие данные используются. У SOAP есть спецификация, в которой описаны требования к передаваемым сообщениям. А JSON у REST не является стандартом хотя бы потому, что его использование не является обязательным. Хотя де-факто во многих компаниях это стандарт.
Согласна, но единственное для меня коммент как будто про диагональ 7+.
Сама пользуюсь PocketBook 632 plus (у нее 6"), для меня идеальный вариант - компактная, E-Ink с подсветкой, долго держит заряд. Поначалу переживала, что не хватит памяти (карты нет), но вместилась довольно большая библиотека. PDF на такой диагонали удобно читать не всякий: с текстовыми с малым количеством иллюстраций никакой разницы с fb2, например, а вот какие-нибудь эл схемы я бы предпочла рассматривать на экране побольше, думаю, планшет был бы оптимален.
Привет. Постараюсь ответить на весь коммент кусочками:
Как я писала во введении, статья призвана познакомить системных аналитиков с протоколом и провести некую "обзорную экскурсию". Для человека, который с протоколом работал, этот момент очевиден. Но при первом знакомстве, как мне кажется, этот момент стоит упомянуть
Да, пожалуй, стоило указать среди источников. Но для обзора я постаралась вынести самые важные из этих пунктов просто и доступно. Плюс добавить личного опыта (почему, например, разработчики просят избегать oneof)
Да, очень крутая и удобная особенность прото - самодокументируемость. Конечно, это не отменяет спецификации, речь была совсем не о том. Давайте будем честны, не всегда спецификация есть и не всегда она актуальна. Тем более, если апи разрабатывает другая команда/компания/оно публичное - нет никаких гарантий, что дока актуальна. С прото контрактами такого нет. Могут быть проблемы с пониманием, как именно использовать методы, но это уже немного другой разговор.
и
Эту тему уже затронули в комменте выше, но повторюсь: JSON у REST не является стандартом хотя бы потому, что его использование не является обязательным. Это самый популярный вариант и многие даже не слышали об альтернативах, но все-таки де-юре не стандарт. Слышала о JSON в gRPC, но особо примеров применения не нашла. Здесь на хабре пишут, что это расширение является очень медленным и мало применимым.
и
Здесь речь скорее о том, что получая ошибку в gRPC, ты получаешь некий числовой и текстовый код ошибки. А в REST в 200 коде (когда уже все, вроде бы, успешно прошло) может где-нибудь в теле приходить еще массив ошибок. Разработчики в этом случае рассуждают примерно так: запрос отработал, значит 200 код, но с данными что-то не то, поэтому вот в теле будет дополнительная ошибка. И, если сваггер неактуальный, как это отловить? Под "нет стандарта использования кодов" я имела ввиду именно эту ситуацию. Один сделает, условно, 3 кода ответа (200, 401, 500), но в 200 положит в тело еще 20 вариантов ошибки. А другой сделает числовой код на каждый случай. И со своей логикой каждый будет прав. А другим потом с этим как-то надо взаимодействовать. Именно в этом, на мой взгляд, состоит недостаток "нет стандарта использования кодов"
Да, действительно, стоило отдельно вынести, а не только указывать в подсказке
Речь о том, какие данные используются. У SOAP есть спецификация, в которой описаны требования к передаваемым сообщениям. А JSON у REST не является стандартом хотя бы потому, что его использование не является обязательным. Хотя де-факто во многих компаниях это стандарт.