REST против gRPC: когда лучше выбрать одно, а когда другое?

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

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

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

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

1. Некоторые люди внедряют gRPC по той же причине, по которой они приняли REST несколько лет назад: дизайн за модным словечком.

2. Многие люди в любом случае осознают, как они реализуют суммы REST в RPC, так почему бы не использовать стандартизированную структуру RPC и не реализовать ее правильно, вместо того, чтобы настаивать на плохой реализации REST?

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

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

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

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

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

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

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

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

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

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

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

Но настоящая причина нынешнего доминирования «ОТДЫХА» не в таких незначительных возможностях. На самом деле это просто успех всемирной паутины. В какой-то момент истории выяснилось, что каждый уже имел производительный, гибкий HTTP-сервер (для обслуживания своего веб-сайта) и надежный HTTP-клиент (для просмотра указанного сайта), поэтому, когда люди начали добавлять машины -читаемые ресурсы, просто было проще и дешевле придерживаться одних и тех же способов HTTP. Они использовали HTTP-методы, заголовки и коды состояния, потому что их веб-серверы уже понимали и регистрировали это. Такие инструменты, как PHP, позволили им сделать это с нулевыми затратами на развертывание по сравнению с их обычными веб-сайтами.

Если для вас не важны единообразие и согласование со Всемирной паутиной, то RPC — проверенный и правильный архитектурный выбор, а gRPC — надежная реализация, которая может избавить вас от некоторых проблем, как объясняет ɐuıɥɔɐɯ.