REST или GraphQL — что выбрать новичку и почему

Представь, что заказываешь еду. REST — это комплексные обеды: просишь «обед №3» и получаешь поднос целиком, даже если суп не нужен. GraphQL — как заказ по списку: пишешь ровно «борщ и компот, без второго» и получаешь только это, одним подходом. Вот и вся суть спора REST против GraphQL — кто решает, что окажется в ответе: сервер или ты.

Сначала — что это вообще такое

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

• REST — набор адресов (эндпоинтов). За каждым типом данных свой адрес: /users/42, /users/42/posts. Дёргаешь адрес — сервер отдаёт заранее заготовленную «карточку» целиком.
• GraphQL — один адрес и язык запроса. Ты прямо в запросе описываешь, какие поля нужны, — и сервер собирает ответ ровно под это.

В чём настоящая разница на практике

Две боли REST, которые новичок чувствует быстро:

• Лишнее (over-fetching). Тебе нужно одно имя, а /users/42 присылает и адрес, и телефон, и дату регистрации. Тащишь по сети лишнее.
• Недостающее (under-fetching). Чтобы собрать один экран, дёргаешь три-четыре адреса по очереди: пользователя, его посты, к ним комментарии. Несколько раундов туда-обратно.

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

Сравнение по делу

| Критерий | REST | GraphQL | |----------|------|---------| | Кривая входа | Пологая — освоишь за вечер | Круче — схема, типы, резолверы | | Кто решает форму ответа | Сервер (фиксированная карточка) | Ты, в самом запросе | | Запросов на сложный экран | Часто несколько | Обычно один | | Лишние/недостающие данные | Бывают регулярно | Берёшь ровно нужное | | Кэширование | Простое, «из коробки» | Сложнее, нужны инструменты | | Для маленького проекта | В самый раз | Часто оверкилл |

Кому что подойдёт

Без увиливаний.

• Новичку и первому проекту — REST. Он проще, его понимают все инструменты, его легче отлаживать и кэшировать. 90% пет-проектов прекрасно живут на REST, и учиться на нём — правильный первый шаг. Как подключить — в гайде как подключить API к проекту.
• GraphQL — когда боль REST стала реальной. Сложные экраны, тянущие данные из кучи мест; мобильное приложение, которому важно не качать лишнее по мобильному интернету; много разных клиентов с разными нуждами к одним данным. Вот тогда гибкость окупает сложность.

Простое правило: не бери GraphQL, потому что «модно». Бери, когда устал бороться с over- и under-fetching на REST. Незнакома эта боль — значит, REST тебе и нужен.

Вопрос: GraphQL — это замена REST или надстройка?

Это другой стиль, а не «новая версия REST». Часто GraphQL ставят слоем поверх тех же данных, что отдаёт REST. Они спокойно сосуществуют: одни части проекта на REST, другие — на GraphQL. Это не «или-или» на всю жизнь.

Вопрос: правда ли, что GraphQL всегда быстрее?

Нет. Один запрос вместо трёх экономит раунды по сети — это плюс. Но сервер всё равно ходит за теми же данными внутри, а сложные GraphQL-запросы могут грузить его сильнее. «Быстрее» — про меньшее число походов клиента, не про магию.

Вопрос: с чего начать, если хочу попробовать GraphQL?

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