REST 2.0 здесь и его имя GraphQL

 schema { query: Query } type Query { movies: [Movie] actors: [Actor] movie(id: Int!): Movie actor(id: Int!): Actor searchMovies(term: String): [Movie] searchActors(term: String): [Actor] } type Movie { id: Int title: String image: String release_year: Int tags: [String] rating: Float actors: [Actor] } type Actor { id: Int name: String image: String dob: String num_credits: Int movies: [Movie] } 

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

GraphQL vs Rest: управление версиями

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

Добавление информации обычно легко как с REST, так и с GraphQL. Добавьте поле, и оно будет передаваться вашим клиентам REST и будет безопасно игнорироваться в GraphQL, пока вы не измените свои запросы. Однако удаление и редактирование информации — это отдельная история.

В REST трудно определить на полевом уровне, какая информация используется. Мы можем знать, что используется конечная точка /movies , но мы не знаем, использует ли клиент заголовок, изображение или и то, и другое. Возможным решением является добавление fields параметров запроса, которые указывают, какие поля возвращать, но эти параметры почти всегда являются необязательными. По этой причине вы часто будете наблюдать эволюцию на уровне конечной точки, где мы представляем новую конечную точку /v2/movies . Это работает, но также увеличивает площадь нашего API, а также увеличивает нагрузку на разработчика, чтобы поддерживать актуальность и полную документацию.

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

Вот как выглядит версия в GraphQL:

GraphQL против REST: кеширование

Кэширование в REST является простым и эффективным. На самом деле, кэширование является одним из шести направляющих ограничений REST и включается в дизайн RESTful. Если ответ от конечной точки /movies/1 указывает, что ответ может быть кэширован, любые будущие запросы к /movies/1 могут быть просто заменены элементом в кэше. Просто.

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

GraphQL vs REST: опыт разработчика

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

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

GraphQL действительно превосходен в отделе опыта разработчиков. Система типов открыла двери для удивительных инструментов, таких как GraphiQL IDE, и документация встроена в саму схему. В GraphQL также есть только одна конечная точка, и вместо того, чтобы полагаться на документацию, чтобы выяснить, какие данные доступны, у вас есть типобезопасный язык и автозаполнение, которые вы можете использовать, чтобы быстро освоиться с API. GraphQL также был разработан для блестящей работы с современными интерфейсными средами и инструментами, такими как React и Redux. Если вы думаете о создании приложения с помощью React, я настоятельно рекомендую вам воспользоваться клиентом Relay или Apollo .

Вывод

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

Если вы заинтересованы в получении дополнительной информации, посмотрите BackQL-скрипт Scaphold.io как сервис . Через несколько минут у вас будет готовый к работе API GraphQL, развернутый в AWS и готовый для настройки и расширения с вашей собственной бизнес-логикой.

Я надеюсь, вам понравился этот пост, и если у вас есть какие-либо мысли или комментарии, я хотел бы услышать от вас. Спасибо за прочтение!