GraphQL vs REST: сравнение по пунктам
И снова рубрика сравнение. Ранее мы писали главное о GraphQL и собрали материалы для изучения, а сегодня попробуем понять, может ли он заменить REST.
Все запросы идут через один эндпоинт
- Если нужно собрать агрегированные данные из различных сервисов, в REST придётся делать несколько запросов к каждому сервису.
- В GraphQL клиенты могут получать данные из нескольких сервисов одним запросом к одной конечной точке.
Получаем только то, что нам нужно
- REST API часто возвращают либо слишком много, либо слишком мало данных. Клиенты обычно получают все доступные поля ресурса, даже если им требуется только часть данных. Такая избыточность вносит свою лепту в увеличении времени ответа. И наоборот, недостаточная выборка возникает, когда клиенту приходится делать несколько запросов к различным эндпоинтам, чтобы получить необходимые данные, что генерирует дополнительную нагрузку и увеличивает время ответа.
- В GraphQL клиент может запросить именно те данные, которые ему нужны, указывая в запросах необходимые поля. Это позволяет избежать избыточной или недостаточной выборки данных, сокращая объем ненужной информации, передаваемой между клиентом и сервером.
Схема данных и типизация
- Классический REST не даёт строгих определений по используемым типам и не определяет схему данных. Однако можно использовать, например, спецификацию OpenAPI.
- GraphQL требует определения схемы, которая описывает все данные и их типы, а также способы доступа клиентов к этим данным или их изменения.
Сложнее версионирование API
- В REST мы легко можем внедрить новую версию метода, не прекращая поддержку старой. Например, если для метода получения статей в блоге нужно добавить новый обязательный параметр в теле входящего запроса, то мы можем создать новую версию API метода POST /v2/articles и добавить новый параметр туда, а POST /v1/articles оставить без изменений. Таким образом, будет соблюдено требование обратной совместимости: потребители смогут пользоваться старой версией, пока не перейдут на новую самостоятельно.
- GraphQL не поддерживает версионирование по URL, так как у нас только одна точка входа. Однако версионирование можно организовать через создание новых query либо настроить специальные предупреждения для устаревших полей, возвращаемых клиенту.
Сложность кэширования запросов
- Кэширование – это один из 6 принципов REST. В REST мы можем кэшировать запросы к эндпоинтам. Это позволяет снизить нагрузку на серверы и ускоряет получение ответа для клиента.
- Хотя физически в GraphQL можно реализовать кэширование на уровне запросов, в реальности этим не занимаются, так как вариаций запросов может существовать бесчисленное множество. В одном запросе вы можете затребовать имя автора, а в следующем – не только имя автора, но и адрес его электронной почты. Именно для таких случаев вам понадобится более филигранный кэш на уровне полей, а реализовать его не так-то просто. Однако, большинство библиотек, построенных поверх GraphQL, предлагают такие механизмы кэширования прямо «из коробки».
Нет кодов состояний
- REST позволяет возвращать любые доступные коды ответов HTTP, что позволяет клиенту понять результат запроса и среагировать на него.
- GraphQL обычно возвращает статус 200 OK даже с ошибкой, но при использовании специальных клиентов эта проблема легко решается.
Что использовать в работе
REST API применяют, если:
- работают с небольшими программами, где нужно обрабатывать простые данные.
- пользователи работают с ними одинаково.
- нет требований к сложным запросам.
GraphQL выбирают, когда:
- у серверного оборудования маленькая пропускная способность и нужно снизить количество ввода-вывода данных.
- в одном адресе нужно объединить множество источников.
- запросы пользователей различны, необходимо прорабатывать разные ответы.
Сравнительная таблица GraphQL и REST
| Критерий | GraphQL | REST |
|---|---|---|
| Чем является | Язык запросов и среда выполнения для API | Архитектурный стиль |
| Парадигма доступа к данным | Запросы и мутации | Обращение к ресурсам |
| Год создания | 2012 | 2000 |
| Транспортный протокол | HTTP/1.1 | HTTP/1.1 |
| Формат сообщений | Преимущественно JSON | JSON, XML и другие |
| Количество эндпоинтов | Один - единая точка входа | Несколько, на каждый ресурс отдельный эндпоинт |
| Гибкость ответа | Возвращает данные в гибкой структуре, определенной клиентом | Возвращает данные в фиксированной структуре, определенной сервером |
| Требуется ли схема | Да | Нет |
| Поддержка HTTP-кодов состояний | Нет | Да |
| Версионирование API | Нет версионирования на уровне URL. Требуется реализация иными способами | Простое версионирование на уровне URL |
| Кэширование | Сложная реализация кэширования из-за единой точки входа и множества вариаций запросов | Проще, можно кэшировать запросы |
| Сложность реализации | Выше порог входа и сложнее кривая обучения | Проще, много готовых решений и фреймворков |
| Лучше всего подходит для | Больших, сложных и взаимосвязанных источников данных | Простых источников данных, где ресурсы четко определены |