🛠 REST, GraphQL и gRPC: гайд для начинающих разработчиков

REST, GraphQL и gRPC: что это такое

REST, GraphQL и gRPC позволяют различным компонентам приложения общаться друг с другом через сеть. Часто REST, GraphQL и gRPC собирательно называют протоколами, хотя первые две технологии не имеют отношения к протоколам в прямом смысле этого слова:

• REST – это архитектурный стиль, концепция построения веб-сервисов на основе HTTP-протокола. В REST ресурсы (данные или функциональность) идентифицируются с помощью URL, а операции с ними выполняются через HTTP-методы (GET, POST, PUT, DELETE). REST работает по принципу запрос-ответ без сохранения состояния.
• GraphQL – это язык запросов для API, разработанный Facebook*. Он позволяет клиентам точно указать, какие данные им нужны, чтобы сервер возвращал им только эти данные. GraphQL решает некоторые ограничения REST, предоставляя более гибкий и эффективный способ получения данных. Например, клиенты могут запрашивать несколько ресурсов за один запрос.
  
• gRPC (Google Remote Procedure Call) — это высокопроизводительный фреймворк для удаленного вызова процедур, разработанный Google. gRPC использует двоичный формат Protocol Buffers, который обеспечивает высокую скорость и эффективность передачи данных в микросервисных архитектурах. Когда говорят о gRPC как о протоколе, имеют в виду Protocol Buffers как протокол сериализации данных в бинарном формате (в противоположность более тяжеловесным текстовым форматам — XML и JSON).
  

Основные отличия между REST, GraphQL и gRPC

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

• Формат данных. REST использует JSON/XML, GraphQL – собственный формат на основе JSON, gRPC – Protocol Buffers.
• Модель запросов. REST использует множество отдельных запросов, GraphQL позволяет объединить запросы, gRPC эффективен для вызовов удаленных процедур.
  
• Производительность. REST и GraphQL менее производительны, чем gRPC при передаче больших объемов данных.
  
• Обработка запросов. REST – запрос-ответ, GraphQL – один запрос с множеством ресурсов, gRPC – удаленный вызов процедур.
  

Эти отличия определяют основные сферы применения: REST подходит для простых веб-сервисов, GraphQL – для приложений с более сложными и детализированными запросами, а gRPC отлично работает в высоконагруженных системах благодаря высокой производительности и поддержке двунаправленной связи. Но обо всем по порядку.

Когда следует использовать REST

REST оптимально использовать в ситуациях, когда нужно:

• Предоставлять данные и услуги через API. Сейчас REST — самый популярный и удобный подход к созданию API, которые предназначены для максимально простого использования другими приложениями и службами.
• Поддерживать множество платформ и языков программирования. REST опирается на стандартные методы HTTP и форматы данных, его можно использовать с широким спектром языков программирования и платформ.
  
• Поддерживать кэширование, которое может улучшить производительность и снизить сетевой трафик.
  
• Создать простой и легковесный API для несложного приложения.
  
• Когда нужно поддерживать большое количество ресурсов.
  

Однако REST – не лучший выбор для API, которые:

• Tребуют обновления в реальном времени.
• Выполняют сложные запросы и манипуляции с данными.

В таких случаях лучше использовать GraphQL или gRPC.

Когда следует использовать GraphQL

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

GraphQL будет оптимальным выбором в ситуациях, в которых:

• Нужно сократить сетевой трафик — GraphQL позволяет клиентам указывать точно, какие данные им нужны, что радикально уменьшает передачу ненужной информации.
• Необходимо поддерживать широкий спектр клиентов — GraphQL поддерживает типизированные запросы, которые можно использовать для обеспечения получения клиентами корректных данных в понятном им формате.
  
• Нужна поддержка обновлений в реальном времени — GraphQL поддерживает обновления в реальном времени через подписки, которые позволяют клиентам получать обновления сразу же, как только они становятся доступны.
  
• Требуется поддержка сложных запросов и манипуляций с данными — GraphQL позволяет клиентам выполнять сложные запросы и операции с данными (фильтрация, сортировка и агрегация) с простым синтаксисом.
  
• Необходима поддержка версионирования — GraphQL позволяет клиентам указывать версию используемой схемы в своих запросах, что облегчает поддержание обратной совместимости по мере развития схемы.
  

Недостаток у GraphQL один – он может потребовать больше времени на настройку и конфигурацию по сравнению с RESTful API, особенно если вы работаете с несколькими языками программирования или платформами.

Когда следует использовать gRPC

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

gRPC станет оптимальным выбором, когда требуется:

• Высокая производительность и эффективность – gRPC использует бинарный протокол, поддерживает двунаправленную потоковую передачу и управление потоком, что делает его намного быстрее и эффективнее других API, особенно в условиях высокой задержки или низкой пропускной способности.
• Поддержка широкого спектра языков программирования – gRPC поддерживает многие языки, включая Java, C++, Python и Go, что облегчает построение распределенных систем на разных платформах.
  
• Поддержка обновлений в реальном времени – двунаправленная потоковая передача позволяет серверам отправлять обновления клиентам в реальном времени.
  
• Обработка больших объемов данных – собственный формат Protocol Buffers более эффективен и компактен по сравнению с JSON и XML.
  
• Использование микросервисов или распределенных систем – gRPC предоставляет мощную и гибкую платформу для создания масштабируемых микросервисов и распределенных систем, способных справляться с большими объемами трафика.
  

Недостатки gRPC – относительная сложность для начинающих разработчиков, невозможность напрямую вызвать службу gRPC из браузера, нечитаемые (без специальных инструментов десериализации) сообщения.

Гибридные API

Важно отметить, что REST, GraphQL и gRPC – не взаимоисключающие технологии: при необходимости их можно комбинировать, чтобы использовать сильные стороны каждого из этих подходов.

REST + GraphQL API

API, сочетающий принципы REST и GraphQL, помогает решить несколько серьезных ограничений REST. Например:

• Получение данных. В REST API требуется несколько разных эндпойнтов для получения связанных данных, тогда как в GraphQL клиент может запросить все необходимые данные за один запрос.
• Передача избыточных данных и множественные запросы. REST API часто возвращают избыточные данные или требуют нескольких запросов для получения всей необходимой информации. GraphQL решает обе эти проблемы, позволяя клиенту запрашивать только необходимые данные.
• Версионирование. REST API обычно использует версионирование для внесения изменений без нарушения работы существующих клиентов. В GraphQLAPI можно развивать без необходимости версионирования, так как клиенты запрашивают только нужные им поля.
  

Рассмотрим основные подходы, которые чаще всего используют для создания гибридных API, сочетающих REST и GraphQL.

REST API с GraphQL запросами

В этом подходе вы по-прежнему используете REST API с разными эндпойнтами для получения ресурсов, например:

• GET /users/:id – получить пользователя по id
• GET /posts/:id – получить пост по id
  

Но дополнительно добавляете новый эндпойнт, обычно /graphql, который принимает запросы на GraphQL. Клиенты могут использовать эту точку для получения связанных данных за один запрос. Например, если клиенту нужно получить пользователя с его постами, то обычный REST требовал бы два запроса, а с GraphQL можно сделать так:

        query {
  user(id: 1) {
    id
    name 
    posts {
      id
      title
      content
    }
  }
}
    

Для реализации этого подхода нужна вспомогательная библиотека – например, Apollo Server для Node.js или Graphene для Python.

REST API со сшиванием GraphQL-схем

Этот подход применяется, когда у вас есть несколько разных микросервисов, каждый из которых предоставляет собственный REST API. Вы создаете GraphQL схему для каждого из этих API, а затем «сшиваете» их в единую схему GraphQL.

Предположим, у вас есть:

• User API: GET /users/:id
• Post API: GET /posts/:id, GET /posts/user/:userId
  

Используя инструменты типа Apollo Federation или GraphQL Tools, можно объединить эти схемы в одну, добавляя нужные распознаватели. В результате получается единый GraphQL API, через который клиенты могут запрашивать данные из разных сервисов:

        query {
  user(id: 1) {
    id
    name
  }
  post(id: 1) {
    id
    title
    content
  }
  postsByUser(userId: 1) {
    id
    title
  }
}
    

GraphQL API как слой абстракции

При использовании этого подхода GraphQL API становится прослойкой между клиентом и REST сервисами:

• Вы определяете собственную GraphQL схему для клиентского API, не привязываясь к существующим REST API напрямую.
• Реализуете резолверы, которые при обработке запросов GraphQL отправляют необходимые HTTP запросы в соответствующие эндпойнты REST API.
  
• GraphQL сервер объединяет полученные из REST API данные в соответствии с определенной GraphQL схемой и возвращает клиенту.
  

Основное отличие абстракции от сшивания схем заключается в том, что в первом случае GraphQL работает как посредник, скрывая взаимодействие с REST API от клиента. Во втором случае GraphQL объединяет существующие схемы, включая GraphQL и REST API, в единую схему для упрощения использования клиентом.

gRPC + REST API

Архитектура гибридного API с использованием gRPC и поддержкой REST обычно состоит из следующих компонентов:

Спецификация (декларативное описание API в формате OpenAPI, определяющее эндпойнты, методы, типы данных и другие детали).

gRPC сервер

• Реализует бизнес-логику API, используя протокол gRPC для высокопроизводительной передачи данных в бинарном формате.
• Серверный код генерируется из .proto-файлов, полученных из OpenAPI спецификации.
  

Граничный прокси (например, Envoy)

• Конфигурируется с использованием бинарного FileDescriptorSet, сгенерированного из .proto-файлов.
  
• Выступает в качестве посредника между клиентами и gRPC сервером.
• Принимает входящие HTTP запросы и транскодирует их в gRPC для отправки на gRPC сервер.
  
• Обратно транскодирует ответы gRPC сервера в HTTP для отправки клиентам.
  

Клиенты gRPC

• Взаимодействуют напрямую с gRPC сервером по бинарному протоколу gRPC.
• Клиентский код генерируется из тех же .proto-файлов.
  

Клиенты REST

• Взаимодействуют с API через HTTP(S), отправляя запросы на граничный прокси.
• Получают ответы в формате REST/JSON, транскодированные из gRPC.
  

Подведем итоги

Выбор между REST, GraphQL и gRPC зависит от конкретных требований проекта к производительности, поддержке платформ, сложности запросов и особенностей архитектуры приложения:

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

При необходимости эти технологии можно комбинировать в гибридных API, используя сильные стороны каждого подхода. Например, можно добавить GraphQL слой поверх существующего REST API или применять gRPC для внутреннего обмена данными, оставляя REST API для внешних клиентов.

* Facebook принадлежит организации Meta, деятельность которой признана экстремистской и запрещена на территории РФ.