Как работать с API на frontend: ошибки, из-за которых ты выглядишь как новичок

Работа с API на frontend — это не просто «сходить за данными и вывести их на экран». Это про управление состояниями, обработку ошибок, структуру кода и предсказуемость поведения приложения.

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

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

Если упростить, API — это способ получить данные с сервера. Ты отправляешь запрос, сервер отвечает, ты показываешь результат пользователю.

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

В хорошем проекте работа с API выглядит предсказуемо. У тебя есть отдельный слой, который отвечает за запросы. Компоненты не знают, куда именно идёт запрос и как он устроен — они просто получают данные.

Ты всегда обрабатываешь три состояния: загрузка, успех и ошибка. Данные проверяются перед использованием. Запросы не дублируются без необходимости.
Это не «перфекционизм». Это база.

Как делают новички?
Отправляют запрос, получают ответ и сразу работают с данными. Если что-то пошло не так, приложение либо падает, либо просто молча ничего не показывает.

Почему это плохо?
В реальной жизни «идеальных» запросов не бывает. Сервер может вернуть 500, API может упасть, пользователь может потерять интернет или получить ответ с неожиданным форматом. Если ты не обрабатываешь ошибки, ты перекладываешь весь негативный сценарий на пользователя.Самое неприятное — такие баги сложно отлавливать. В разработке всё работает, а в продакшене пользователи получают пустой экран.

Как правильно?
Нужно обрабатывать:
— HTTP-статусы;
— сетевые ошибки;
— неожиданные данные.
И обязательно показывать пользователю понятное состояние.

Как делают новички?

Пишут запрос прямо внутри компонента: URL, логика, обработка — всё в одном месте.

useEffect(() => {
fetch('/api/user')
.then(res => res.json())
.then(setUser);
}, []);

Почему это плохо?
Пока у тебя один экран — это выглядит нормально. Но как только проект растёт, код превращается в хаос. Один и тот же URL размазан по всему приложению, изменить API становится больно, а переиспользовать логику невозможно.
Кроме того, такой код тяжело тестировать и поддерживать.

Как правильно?
Разделять ответственность: компоненты — про UI, API — про данные.

// api/user.js
export async function getUser() {
const res = await fetch('/api/user');
if (!res.ok) throw new Error('Ошибка');
return res.json();
}

Теперь компоненту всё равно, как устроен запрос. Это уже уровень мышления мидла.

Как делают новички?
Вызывают один и тот же запрос в нескольких местах. Иногда даже не замечают, что запрос уходит дважды при рендере.

Почему это плохо?
Во-первых, это лишняя нагрузка на сервер. Во-вторых, это замедляет интерфейс. В-третьих, могут появляться странные баги: данные приходят в разное время, состояние и UI ведут себя нестабильно.
Особенно часто это происходит в React, когда useEffect срабатывает несколько раз.

Как правильно?
Централизовать работу с данными и использовать кеширование.
Например, React Query автоматически:
— кеширует данные;
— не делает лишние запросы;
— синхронизирует состояние.
Мидл не просто «делает запрос», он управляет жизненным циклом данных.

Как делают новички?
Сразу рендерят данные. Если данных нет — просто ничего не показывают.

Почему это плохо?
Пользователь не понимает, что происходит. Это одна из самых частых проблем UX.
— Нет индикатора загрузки → кажется, что всё зависло;
— Нет обработки ошибки → кажется, что ничего не работает;
— Нет empty-состояния → пользователь не понимает, что данных просто нет.

Как правильно?
Всегда думать через состояния:
— загрузка (loading);
— ошибка (error);
— пустой результат (empty);
— успешный ответ.
Это не «дополнительная работа». Это обязательная часть интерфейса.

Как делают новички?

Сразу используют response: const name = data.user.name;

Почему это плохо?
API — это внешний источник. Он может измениться. Поле может исчезнуть, прийти null или иметь другой тип.
В итоге:
— падает приложение;
— появляются баги, которые сложно воспроизвести;
— ломается UI.

Как правильно?
Минимум — проверять наличие данных. Лучше — использовать схемы.

Как делают новички?
Запросы разбросаны по проекту: часть в компонентах, часть в хуках, часть где-то ещё.

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

Как правильно
Структурировать API по доменам:
api/
user.js
auth.js
products.js

Это кажется мелочью, но именно такие вещи отличают «учебный проект» от рабочего.

Код мидла — это не про «больше знаний» и не про «сложнее конструкции». Это про предсказуемость и контроль.

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

У мидла API не «размазан» по компонентам. Есть понятный слой работы с данными, где сосредоточена вся логика запросов. Компоненты не знают, откуда приходят данные — они просто получают результат.

Ошибки не игнорируются и не «ловятся где получится». Они обрабатываются централизованно и осмысленно: с логами, с понятными сообщениями и с учётом пользовательского опыта.
Состояния всегда учтены. Мидл не оставит интерфейс в подвешенном состоянии, где непонятно, загрузка идёт или всё сломалось. Он заранее продумывает, что увидит пользователь в каждом сценарии.

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

И самое важное — код становится читаемым. Не за счёт комментариев, а за счёт структуры. Названия функций, разделение логики, понятные зависимости — всё это делает код удобным для поддержки.

Главное отличие — мышление. Джун пишет код, чтобы он заработал. Мидл пишет код, чтобы он продолжал работать завтра, через месяц и после изменений API.

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

Старайся разделять ответственность. Компоненты должны отвечать за отображение, а не за работу с API. Это базовый принцип, который сильно упрощает жизнь на любом проекте.
Всегда обрабатывай ошибки, даже если «всё работает». В реальности не работает ничего идеально, и твой код должен быть к этому готов.

Думай про пользователя. Когда ты делаешь запрос, за этим всегда стоит человек, который ждёт результат. Покажи загрузку, объясни ошибку, обработай пустые данные. Это отличает «рабочий код» от «удобного интерфейса».

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

Используй инструменты осознанно. Fetch и axios — это просто способы отправить запрос. React Query или SWR — это уже уровень управления данными. Не обязательно использовать всё сразу, но важно понимать, зачем эти инструменты существуют.

И главное — делай код предсказуемым. Если ты сам через неделю не сможешь быстро разобраться в своём коде, значит, его нужно упростить.

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

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

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

И хорошая новость в том, что этот переход — не про годы. Это про то, как ты начинаешь думать уже сейчас.

Что лучше: fetch или axios?
Оба инструмента решают одну задачу — отправить HTTP-запрос. Fetch встроен в браузер и даёт больше контроля, но требует чуть больше ручной настройки. Axios удобнее из коробки: есть обработка JSON, интерцепторы, единый формат ошибок. На практике выбор не критичен — важнее, как ты строишь работу с API в целом.

Нужно ли использовать React Query?
Не обязательно, особенно на маленьких проектах. Но как только появляется несколько запросов, кеширование и синхронизация данных, такие инструменты начинают экономить время и сильно упрощают код. Это уже не «библиотека», а слой управления состоянием данных.

Как правильно работать с API в JavaScript?
Через асинхронные функции, с обязательной обработкой ошибок и чётким разделением логики. Важно не просто получить данные, а управлять их состоянием: загрузка, ошибка, успех.

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

Кстати, несколько статей уже вышли — в каждой из них тоже спрятаны слова, поэтому переходи и читай внимательно:

• Как перейти с Python или JavaScript на Go: подробное руководство для разработчиков
• Ошибка 404, 500 и другие: зачем тестировщику понимать бэкенд
• 15 ошибок новичков в CSS, которые ломают вёрстку
• Spring Boot 3: что нового и как перейти с предыдущих версий