Последнее изменение: 11 января 2019 г.

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

В то время как REST был широко признан «де-факто» для разработки независимых микросервисов без сохранения состояния, GraphQL — новичок в области быстрой разработки API.

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

Что такое ОТДЫХ?

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

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

Каждый ресурс идентифицируется URL-адресом. Вы получаете данный ресурс, отправляя HTTP-запрос, который может выглядеть примерно так:

/users/<id>/posts

Сервер обрабатывает ваш запрос и возвращает что-то вроде этого:

{
  "posts": [
    {
      "title":"My latest post",
      "author":"Sam",
      "views":33
    },
    {
      "title":"My other post",
      "author":"Sam",
      "views":14
    },
    {
      "title":"My first post",
      "author":"Sam",
      "views":53
    }
  ]
}

Для пользователя с заданным ‹id› служба возвращает объект JSON с массивом объектов публикации.

Что такое GraphQL?

В отличие от REST, GraphQL — это реальный язык запросов приложений для выполнения HTTP-запросов, которые возвращают указанные ресурсы. Хотя GraphQL в конечном итоге использует тот же протокол HTTP для получения информации с сервера, он использует систему типов, определенную в схеме. Эта схема определяет типы запросов, которые можно выполнять, и данные, которые они возвращают.

В отличие от REST, GraphQL создает единую конечную точку API для связи с сервером.

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

query {
  User(id: <id>) {
    posts {
      title,
      author,
      views
    }
  }
}

Сервер обрабатывает запрос и возвращает:

{
  "posts": [
    {
      "title":"My latest post",
      "author":"Sam",
      "views":33
    },
    {
      "title":"My other post",
      "author":"Sam",
      "views":14
    },
    {
      "title":"My first post",
      "author":"Sam",
      "views":53
    }
  ]
}

Обратите внимание, что точно такой же ответ JSON возвращается с использованием GraphQL….

Так в чем смысл?

Из примеров видно, что и GraphQL, и REST дают одинаковый результат. Запрос GraphQL кажется немного более подробным, чем простой запрос GET, но оба в конечном итоге используют один и тот же протокол для возврата одного и того же. Так в чем же дело?

Перевыборка и недовыборка данных

Одной из основных причин, по которой GraphQL предпочтительнее REST, является точность, с которой данные извлекаются с сервера. Хотя наша базовая конечная точка /users/‹id›/posts дала нам необходимые данные, она могла дать нам больше, чем мы просили. Например, что, если бы мы хотели, чтобы для каждого сообщения возвращался только заголовок?

Это известно как «перевыборка», поскольку мы получили больше, чем просили. В частности, нам вернули автора и просмотры вместе с заголовком.

Другой сценарий может заключаться в том, что вам нужно больше информации о каждом сообщении. В дополнение к просмотрам, авторам и заголовкам вам также может потребоваться количество лайков для данного сообщения и т. д. Это считается «недостаточной выборкой» и приводит к дополнительным запросам, необходимым для каждого возвращаемого объекта сообщения.

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

И ты не ошибаешься. Но это потребует дополнительной работы по разработке и большей координации между различными командами.

В качестве альтернативы, с GraphQL мы могли бы просто изменить исходный запрос, чтобы решить проблему «избыточной выборки»:

query {
  User(id: <id>) {
    posts {
      title
    }
  }
}

или проблема «недовыборки»:

query {
  User(id: <id>) {
    posts {
      title,
      author,
      views,
      followers
    }
  }
}

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

Одна просьба, чтобы править ими всеми…

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

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

GraphQL против REST: плюсы и минусы

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

Плюсы ОТДЫХА:

  • широко принят – REST существует с 2000 года и до сих пор остается одним из самых популярных подходов к реализации веб-сервисов.
  • многократное использование — с помощью REST вам будет проще разрабатывать независимые микросервисы, работающие независимо друг от друга. Микросервисы (в идеале) полностью отделены от клиентов, что позволяет нескольким приложениям получать к ним доступ.
  • кеширование — REST по своей сути поддерживает кэширование намного лучше, чем GraphQL. Это обеспечивает лучшую производительность из коробки.

ОТДЫХ минусы

  • чрезмерное количество циклов обмена — больше конечных точек требует больше запросов. Мы увидели, как проблема недовыборки может привести к избыточным запросам по сети.
  • управление версиями — чтобы избежать критических изменений, REST API должны реализовывать управление версиями, чтобы рабочие службы продолжали работать даже после внесения обновлений. Это может привести к путанице, поскольку выпускается все больше и больше версий вашего API.
  • overfetching — загрузка ненужных данных.
  • недостаточная выборка — получение недостаточного количества данных, что приводит к дополнительным запросам.
  • усилия по координации — более сложно разрабатывать клиентские части независимо от серверных частей, поскольку новые требования требуют новых конечных точек (или модификации существующих конечных точек).

Плюсы GraphQL

  • схема — определяя схему с типами данных и запросов, GraphQL создает контракт между клиентом и сервером, делая данные доступными для клиента более очевидными. Фронтенд-разработчикам не нужно заботиться о бэкенде.
  • легко начать — вам не нужно быть экспертом в области архитектуры веб-сервисов, чтобы начать создавать/использовать GraphQL.
  • точность — вы можете получить именно те данные, которые ищете, без дополнительных конечных точек или модификации этих конечных точек. GraphQL более эффективно решает проблему перевыборки/недостаточной выборки.

Минусы GraphQL

  • проблемы с масштабируемостью. С GraphQL легко начать работу, но он может стать проблемой производительности по мере появления и увеличения количества сложных запросов.
  • ограничения схемы. С GraphQL вы привязаны к определенной схеме. Это может вызвать головную боль, когда вы хотите получить более подробные ответы, чем предусмотрено.
  • все еще довольно новый — GraphQL по-прежнему считается новичком в мире. Есть только несколько избранных клиентов, которые хорошо его реализуют (Apollo, Relay и Lokka среди самых популярных клиентов GraphQL).

Вывод

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

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

Первоначально опубликовано на www.stackchief.com.