REST vs gRPC: когда я должен выбирать один за другим?

Я вижу все больше и больше программных организаций, использующих gRPC в своих сервис-ориентированных архитектурах, но люди все еще используют REST. В каких случаях имеет смысл использовать gRPC, и когда имеет смысл использовать REST для межсервисной связи?

Интересно, что я столкнулся с проектами с открытым исходным кодом, которые используют как REST, так и gRPC. Например, Kubernetes и Docker Swarm используют gRPC в некоторой степени для координации кластеров, но также предоставляют API REST для взаимодействия с ведущими/ведущими узлами. Почему бы не использовать gRPC вверх и вниз?

Ответ 1

Если все сделано правильно, REST улучшает долгосрочную эволюционируемость и масштабируемость за счет производительности и дополнительной сложности. REST идеально подходит для сервисов, которые должны разрабатываться и поддерживаться независимо, например, самой сети. Клиент и сервер могут быть слабо связаны и меняться, не нарушая друг друга.

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

Однако большинство так называемых REST-сервисов вообще не следуют REST, потому что REST стал просто модным словом для любого вида HTTP API. На самом деле, большинство так называемых REST API настолько тесно связаны между собой, что не дают никаких преимуществ по сравнению с RPC.

Учитывая это, мои несколько циничные ответы на ваш вопрос:

Некоторые люди внедряют gRPC по той же причине, по которой они использовали REST несколько лет назад: дизайнерское модное слово.
Многие люди в любом случае понимают, как они реализуют REST-значения в RPC, так почему бы не использовать стандартизированную среду RPC и правильно ее реализовать, вместо того чтобы настаивать на плохих реализациях REST?
REST - это решение проблем, возникающих в проектах, охватывающих несколько организаций и имеющих долгосрочные цели. Возможно, люди понимают, что им действительно не нужен REST, и ищут лучшие варианты.

Ответ 2

Обещанием REST всегда был унифицированный интерфейс. Идеальный клиент REST мог бы общаться с широким спектром ресурсов RESTful, даже с теми, которые не существовали на момент кодирования клиента.

К сожалению, этот идеал так и не был реализован, за исключением оригинального случая REST - Всемирной паутины удобочитаемых документов.

На этом этапе большинство интерфейсов, которые называют себя "RESTful", на самом деле представляют собой барочный тип RPC, где данные запросов и ответов размазаны по методам, строкам запросов, заголовкам, кодам состояния, полезным нагрузкам, все в различных хрупких форматах.

Большая часть единообразия в современных интерфейсах RESTful находится в головах разработчиков. Они "знают", что POST /orders/, вероятно, собирается добавить новый заказ. Но им все равно приходится программировать своих клиентов так, чтобы они "знали", что для каждого API, с которым они общаются, часто допускается множество ошибок.

Тем не менее, есть некоторая однородность, которая может быть полезна в коде. Например, если у вас есть API-интерфейс RESTful, вы часто можете добавить к нему прозрачный, точно настраиваемый слой кэширования практически бесплатно. Это возможно, потому что (семантически правильные) сообщения HTTP уже содержат всю стандартизированную информацию, необходимую для кэширования: метод запроса, URL, код состояния, Cache-Control, Vary и все такое. В gRPC вы должны использовать собственное кэширование.

Но настоящая причина нынешнего доминирования "REST" заключается не в таких мелочах. Это действительно просто успех Всемирной паутины. В какой-то момент в истории выяснилось, что у всех уже есть эффективный, гибкий HTTP-сервер (для обслуживания их веб-сайта) и надежный HTTP-клиент (для просмотра указанного сайта), поэтому, когда люди начали добавлять машиночитаемые ресурсы, это было просто Проще и дешевле придерживаться тех же HTTP-способов. Они использовали HTTP-методы, заголовки и коды состояния, потому что это то, что их веб-серверы уже поняли и зарегистрировали. Такие инструменты, как PHP, позволяли им делать это с минимальными затратами на развертывание на своих обычных веб-сайтах.

Если для вас не важны единообразие и согласованность со Всемирной паутиной, то RPC - это проверенный и правильный архитектурный выбор, а gRPC - это надежная реализация, которая может избавить вас от некоторых проблем, как объясняет Чуйч.

Ответ 3

В зависимости от будущей дорожной карты gRPC, люди продолжат переходить на нее и разрешать REST (через HTTP) "тихий".

gRPC удобнее во многих отношениях:

Обычно быстро (как супер-быстро)
(Почти) Нет "дихотомии дизайна" - какую правильную конечную точку использовать, какой правильный HTTP-глагол использовать и т.д.
Не имеет дело с беспорядочной сериализацией ввода/ответа, поскольку gRPC имеет дело с сериализацией - более эффективным кодированием данных и HTTP/2, который ускоряет работу с мультиплексированными запросами по одному соединению и сжатием заголовка
Определите/Объявите свой ввод/ответ и сгенерируйте надежных клиентов для разных языков (конечно, те, которые "поддерживаются", это ОГРОМНОЕ преимущество)
Формализованное множество ошибок - это спорно, но до сих пор они более непосредственно применимы к случаям использования API, чем коды состояния HTTP

В любом случае вам придется иметь дело со всеми проблемами gRPC также, поскольку ничто в этом мире не является непогрешимым, но пока оно "выглядит лучше", чем REST - и фактически доказало это.

Я думаю, что вы можете получить лучшее из обоих миров. В любом случае gRPC в основном следует семантике HTTP (через HTTP/2), но явно разрешает полнодуплексную потоковую передачу, отклоняясь от типичных соглашений REST, так как он использует статические пути по соображениям производительности во время диспетчеризации вызова в качестве парсинга параметров вызова из путей - параметров запроса и полезной нагрузки. кузов добавляет латентность и сложность.