🆚 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 выбирают, когда:
➖ у серверного оборудования маленькая пропускная способность и нужно снизить количество ввода-вывода данных
➖ в одном адресе нужно объединить множество источников
➖ запросы пользователей различны, необходимо прорабатывать разные ответы
📎 Ссылки
1. REST API vs GraphQL: в чём между ними разница — МТС
2. В чем разница между GraphQL и REST? — Amazon
3. Сравнение REST и GraphQL
4. GraphQL vs REST: 4 Critical Differences
5. GraphQL vs REST - кто круче? — видео
#сравнение #api #интеграции
И снова рубрика #сравнение.
Ранее мы писали главное о 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 выбирают, когда:
➖ у серверного оборудования маленькая пропускная способность и нужно снизить количество ввода-вывода данных
➖ в одном адресе нужно объединить множество источников
➖ запросы пользователей различны, необходимо прорабатывать разные ответы
📎 Ссылки
1. REST API vs GraphQL: в чём между ними разница — МТС
2. В чем разница между GraphQL и REST? — Amazon
3. Сравнение REST и GraphQL
4. GraphQL vs REST: 4 Critical Differences
5. GraphQL vs REST - кто круче? — видео
#сравнение #api #интеграции