GraphQL против REST: все, что вам нужно знать

Может быть непросто выбрать технологии, которые будут включены в стек технологий вашего следующего проекта. Во многих случаях — и особенно когда дело доходит до выбора между GraphQL и RESTful API — все дело в выборе следующей лучшей архитектуры дизайна API.

Существует четыре основных способа создания API: SOAP, GRPC, REST и GraphQL. Мы часто ограничиваемся REST и GraphQL всякий раз, когда хотим создавать API. Это связано с тем, что REST изменил традиционные способы создания API с помощью SOAP и GRPC.

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

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

Прежде чем мы углубимся в детали, давайте сначала изучим значение API GraphQL и RESTful.

Что такое GraphQL?

GraphQL — это язык запросов API, а также среда выполнения для ответов на эти запросы с помощью существующих данных. Он также оснащен мощными инструментами для обработки даже самых сложных запросов.

Главной особенностью GraphQL является его способность запрашивать и получать только запрошенные данные — не более того. Это значительно упрощает масштабирование ваших API вместе с вашим приложением.

Самая захватывающая часть GraphQL — это его способность предоставлять вам все данные в одной конечной точке.

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

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

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

Компании, использующие GraphQL

Ниже приведен список лишь некоторых компаний и приложений, активно использующих GraphQL на своих серверах.

Фейсбук

Facebook создал GraphQL и с 2012 года использует его в производстве для поддержки своих мобильных приложений. Многомиллиардная социальная сеть открыла исходный код спецификации GraphQL в 2015 году, сделав ее доступной во многих средах и для команд любого размера. .

Гитхаб

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

Пинтерест

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

Многие другие компании с оборотом в миллиард долларов, такие как Intuit, Shopify, Coursera и Airbnb, используют в своих приложениях GraphQL. И это далеко идущее предпочтение REST только продолжает расти.

Что такое RESTful API?

REST расшифровывается как «Передача репрезентативного состояния», который представляет собой архитектурный стиль программного обеспечения для распределенных систем гипермедиа. Он определяет принципы и ограничения для обмена ресурсами между сервером и клиентами.

Если эти принципы соблюдаются в API, приложение этого API называется «RESTful». WordPress REST API — яркий тому пример.

Ниже приведены некоторые принципы и ограничения, которым должен соответствовать API, чтобы называться Restful API:

• Разделение клиент-сервер: клиенты (внешняя часть) и сервер (внутренняя часть) полностью разделены и могут обмениваться данными только через конечные точки.
• Единый интерфейс: данные, отображаемые в интерфейсе, идентичны на всех устройствах.
• Отсутствие состояния: сервер не помнит, выполняется ли текущий запрос в первый раз или нет. Каждый раз, когда делается запрос, он должен включать всю информацию, необходимую для его обработки с нуля.
• Кэшируемость. Кэширование и хранение сеансов разрешены, но они должны быть настроены таким образом, чтобы конечные пользователи могли отказаться от кэширования данных.
• Архитектура многоуровневой системы: API-интерфейсы должны быть спроектированы таким образом, чтобы ни клиент, ни сервер не могли сказать, общаются ли они напрямую или через посредника.

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

Преимущества GraphQL

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

Получение данных через единую конечную точку API

Главным преимуществом GraphQL является возможность доступа к любой или всем точкам данных через единую конечную точку API.

Одна из наиболее распространенных проблем с RESTful API — наличие слишком большого количества конечных точек для доступа к информации. В GraphQL у вас есть только одна конечная точка, поэтому вам не нужно отправлять несколько запросов для получения различной информации об объекте.

На приведенной ниже диаграмме показан наглядный пример извлечения ресурсов с использованием RESTful API и GraphQL. Вы можете видеть, что есть только одна конечная точка для доступа к ресурсу на сервере GraphQL, в то время как для доступа к различным ресурсам в RESTful API требуется несколько конечных точек API.

Нет перевыборки или недовыборки

Проблема избыточной или недостаточной выборки — известная проблема с RESTful API. Это когда клиенты загружают данные, обращаясь к конечным точкам, которые возвращают фиксированные структуры данных, или же они получают либо больше, либо меньше, чем ожидали.

Излишняя выборка приводит к тому, что запрос получает — или «выбирает» — больше данных, чем требуется для данного запроса. Представьте, что вы выбираете всех пользователей в таблице с намерением отобразить их имена пользователей на своей домашней странице. В этом случае избыточная выборка вернет все данные о каждом пользователе, включая (но не только) имя.

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

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

Лучшее управление сложными системами и микросервисами

GraphQL может унифицировать и скрыть сложность интегрированных нескольких систем.

Например, предположим, что мы хотим перейти от монолитного серверного приложения к микросервисной архитектуре. API GraphQL помогает поддерживать связь между различными микросервисами, объединяя их в одну схему GraphQL.

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

Быстро и безопасно

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

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

Преимущества ОТДЫХА

Несмотря на растущую популярность GraphQL, REST по-прежнему остается одним из самых популярных стандартов API. Давайте посмотрим, почему.

• Кривая обучения: API RESTful проще всего изучить и понять. Это его главное преимущество перед другими API.
• Сериализация: REST предлагает гибкий подход и форматы для сериализации данных в JSON.
• Кэширование: REST API может справляться с высокой нагрузкой с помощью прокси-сервера HTTP и кеша.
• Сложный запрос: API-интерфейсы REST имеют отдельную конечную точку для разных запросов, что помогает сделать сложный запрос более управляемым, чем в других API-интерфейсах.
• Чистота и простота: API-интерфейсы REST элегантны, просты и понятны. Их легко исследовать.
• Стандартные HTTP-процедуры: REST использует стандартные вызовы HTTP-процедур для получения данных и выполнения запросов.
• Клиент/сервер: это означает, что его бизнес-логика отделена от представления. Таким образом, вы можете изменить одно, не влияя на другое.
• REST не имеет состояния: все сообщения, которыми обмениваются клиент и сервер, имеют весь контекст, необходимый для того, чтобы знать, что делать с сообщением.

Недостатки GraphQL

Теперь, когда мы обсудили преимущества GraphQL и REST, давайте рассмотрим некоторые недостатки GraphQL:

• Сложная кривая обучения: GraphQL не так прост в освоении, как REST. Самой сложной частью создания GraphQL API является разработка схемы. Это требует много времени и знаний предметной области.
• Загрузка файлов: GraphQL не имеет встроенной функции загрузки файлов. Это можно обойти с помощью кодирования Base64, но стоимость кодирования и декодирования таким образом может быть трудоемкой и дорогостоящей.
• Веб-кэширование. Кэширование помогает уменьшить частый трафик на сервер, что ускоряет запросы и процесс ответа, сохраняя часто используемую информацию рядом с сервером. GraphQL не поддерживает и не полагается на методы кэширования HTTP, а вместо этого зависит от механизмов кэширования клиентов Apollo или Relay.
• Не подходит для небольших приложений: GraphQL может быть не лучшей архитектурой API для создания небольшого приложения. Если вашему приложению не требуются более гибкие запросы, предлагаемые GraphQL, вам подойдет REST.
• Сложная проблема с запросом: способность GraphQL предоставить клиенту именно то, что он хочет, также может привести к проблемам с распространением запроса. Если клиент отправляет слишком много вложенных запросов, это может привести к отправке неправильных запросов, что может занять очень много времени для сервера. Для удовлетворения таких запросов лучше использовать REST с настраиваемыми конечными точками.

Недостатки ОТДЫХА

Теперь давайте обратим внимание на некоторые недостатки REST:

• Множественные круговые поездки: самая большая проблема с REST API — природа многочисленных конечных точек. Это означает, что клиент, чтобы получить все ресурсы для полного приложения, должен совершить бесчисленное количество циклов, чтобы получить данные.
• Избыточная и недостаточная выборка . Проблема избыточной и недостаточной выборки является основным недостатком RESTful APIS. Это может привести к задержке ответов из-за получения больших нежелательных полезных данных.
• Иерархия. Поскольку REST API построены на ресурсах, ссылающихся на URI, они плохо подходят для ресурсов, которые естественным образом не организованы или не доступны в простой иерархии.

Зачем использовать GraphQL вместо REST

Далее мы обсудим, почему вы можете захотеть рассмотреть GraphQL для своей будущей разработки API вместо RESTful API.

Строго типизированная схема

GraphQL использует строгую систему типов для определения возможностей API. В GraphQL язык определения схемы (SDL) используется для определения параметров, связанных с тем, как клиент получает доступ к данным сервера. Все API-интерфейсы, предоставляемые клиенту, записываются в SDL, что решает проблему несогласованности данных, наблюдаемую в API-интерфейсах RESTful.

Нет избыточной или недостаточной выборки

Проблема избыточной или недостаточной выборки — это известная проблема с RESTful API, из-за которой клиенты возвращают либо больше, либо меньше информации, чем они запросили. GraphQL решает эту проблему, предоставляя клиенту средство для указания необходимой информации, а затем возвращая точно — и только — эту конкретную информацию.

Несколько конечных точек

Одна из самых больших проблем RESTful API — слишком много конечных точек для доступа к информации.

Предположим, вы хотите получить доступ к конкретному пользователю через его идентификационный номер. Вам будет представлена ​​конечная точка, такая как /users/1 . Но если вы хотите получить доступ к фотографиям этого пользователя, вам придется отправить запрос на другую конечную точку, например /users/1/photos .

В GraphQL у вас есть одна конечная точка, и вам не нужно отправлять несколько запросов для получения различной информации о пользователе.

Вскрытие GraphQL против REST

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

Производительность

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

Сложность запроса

Поскольку конечные точки не разделены на несколько конечных точек, запросы GraphQL со временем могут становиться все более сложными. С другой стороны, конечные точки API RESTful разделены, что ограничивает API RESTful простыми запросами.

Популярность и поддержка сообщества

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

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

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

Кривая обучения

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

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

Резюме

GraphQL — это новая технология, которая следует за архитектурными шаблонами RESTful API, точно так же, как REST был введен для решения проблем с шаблонами SOAP API.

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

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

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