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

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

Что такое REST API?

REST API - это программный архитектурный стиль или шаблон проектирования для API, представленный в 2000 году Роем Филдингом. REST означает «передача репрезентативного состояния», что означает, что сервер передает клиенту представление о состоянии запрошенного ресурса после вызова API.

Чтобы прояснить ситуацию, сначала разберемся, что такое API.

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

REST API взаимодействует с помощью HTTP-запросов с методами GET, POST, PUT и DELETE для управления данными, которые в основном используются при разработке веб-сервисов. С помощью REST API мы отправляем запрос от одного программного обеспечения к URI ресурса, а затем второе программное обеспечение повторно отправляет ресурсы как JSON, XML или HTML.

В RESTful API все считается ресурсом, то есть объектом, о котором API может предоставлять информацию. Рассмотрим Twitter, где ресурсами могут быть, например, пользователь или твит.

Графическое представление того, как работает REST API и что происходит в фоновом режиме вызова:

REST API

Клиент отправляет запрос, используя один из методов REST API, следующий ответ сервера с данными JSON, XML или HTML.

6 ограничений API RESTful.

1. Единый интерфейс - это ограничение делится на 4 элемента:

1. стандарт URI используется для идентификации ресурса;
2. манипулирование данными должно определяться доступными методами (GET, PUT, POST, DELETE);
3. информативные сообщения;
4. гиперссылки и шаблоны URI для отделения клиента от конкретной структуры URI;

2. Без сохранения состояния - каждое взаимодействие между сервером и клиентом не должно сохранять состояния. Это означает, что сервер не хранит никаких данных о предыдущем HTTP-запросе и принимает каждый запрос как новый. Если приложение требует аутентификации для выполнения некоторых данных, следующие вызовы должны содержать всю необходимую информацию для выполнения запроса, такую как данные авторизации или аутентификации.

3. Клиент-сервер - клиентская и серверная части приложения должны быть независимыми, и единственное общее для соединений должно быть URI API.

4. Cacheable - кэширование в REST API следует применять по возможности. Оно может быть реализовано как на стороне клиента, так и на стороне сервера.

5. Многоуровневая система - REST позволяет нам размещать количество серверов между клиентом, отправляющим запрос, и сервером, отвечающим на запрос. Например, аутентификация пользователя может выполняться на другом сервере, а не при получении заказов пользователей.

6. Код по запросу (необязательно) - это ограничение является параметрами, но вместо JSON или XML REST API может отвечать исполняемым кодом, таким как код виджета пользовательского интерфейса, который можно визуализировать.

Анатомия запроса REST API

Запрос REST API может состоять из 4 элементов, но не каждый из них является обязательным. Для каждого вызова API требуется конечная точка, которая является URL-адресом, который мы запрашиваем. Конечная точка состоит из корневой конечной точки и пути, который определяет запрашиваемый нами ресурс.

Следующим элементом, необходимым для вызова REST API, является метод. На этом этапе вы должны подумать, какое действие будет выполнено. В REST API есть четыре наиболее часто используемых метода:

1. GET - получить данные с сервера
2. POST - для создания нового элемента
3. PUT - для обновления данных
4. DELETE - удалить элемент

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

Что такое GraphQL?

GraphQL был выпущен Facebook в 2015 году, и это язык запросов с открытым исходным кодом, который помогает нам более эффективно разрабатывать, создавать и использовать API. Для REST API - это сильная конкуренция.

В GraphQL мы отправляем запросы на сервер и возвращаем данные в формате JSON клиенту. Он был разработан для решения проблем с гибкостью и эффективностью, которые иногда возникают с REST API.

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

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

Как работает GraphQL?

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

Когда у нас определены схемы, мы можем сравнить их с запросами, чтобы убедиться, что мы получим ответ сервера.

Когда запрос GraphQL отправляется на сервер, он интерпретируется по схеме и разрешает данные клиента.

Запрос отправляется от клиента, проверяется в схеме, затем разрешается с источником данных и возвращается клиенту.

GraphQL может иметь три основных типа операций:

1. query  - читать данные
2. mutation  - для сохранения данных
3. subscription   - для получения данных в реальном времени

Различия между REST и GraphQL

1. Количество конечных точек

В REST API есть несколько конечных точек, и мы получаем ресурсы, вызывая разные пути для разных типов данных. Например, когда мы вызываем http://api.com/users, мы вызываем пользовательский ресурс, но не можем вызвать ту же конечную точку, чтобы получить все комментарии, которые пользователь написал в блоге. Для этого мы должны вызвать другую конечную точку http://api.com/users/:id/comments.

В GraphQL есть только одна конечная точка; обычно это http://api.com/graphql. Запросы определяются на основе запросов или изменений. Мы можем запрашивать разные ресурсы на одной конечной точке, просто связывая запрос.

2. Получение данных

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

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

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

В GraphQL мы можем создать запрос таким образом, чтобы предоставить все необходимые данные для определенного представления, не слишком много и не слишком мало. Это помогает уменьшить количество HTTP-запросов, что повышает производительность и безопасность приложения.

3.Версия

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

И REST API, и GraphQL - отличные решения для API, и у обоих есть свои сильные и слабые стороны.

GraphQL позволяет избежать избыточной и недостаточной выборки, это всего лишь одна конечная точка, и ее очень легко обновить.

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

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

А какой ваш любимый метод создания API?