Что такое API

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

В frontend под API часто имеют в виду серверный HTTP API. Например, интерфейс вызывает GET /api/products, получает список товаров в JSON и рендерит карточки. Но само понятие шире: fetch, DOM, браузерная геолокация, SDK платежного сервиса и методы библиотеки тоже имеют API.

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

Хороший ответ лучше строить не как определение из словаря, а как понятную цепочку.

1. Сначала скажите, что API это контракт взаимодействия.
2. Затем привяжите к frontend: запросы к серверу, endpoints, HTTP методы, JSON, статусы.
3. Потом добавьте практический риск: UI зависит от стабильности контракта и обработки ошибок.
4. В конце приведите короткий пример из интерфейса.

Пример ответа:

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

Для frontend API почти сразу превращается в состояния интерфейса. Пока запрос идет, нужен loading state. Если данных нет, нужен empty state. Если сервер вернул ошибку или пользователь не авторизован, нужен понятный сценарий, а не сломанный компонент.

Плохой вариант: сделать запрос, сразу вызвать json() и считать, что данные всегда нужной формы. Такой код ломается при 401, 500, пустом ответе, изменении поля или быстром переходе пользователя на другую страницу.

Более безопасный пример:

import { useEffect, useState } from "react";

export function Products() {
  const [products, setProducts] = useState([]);
  const [status, setStatus] = useState("loading");

  useEffect(() => {
    const controller = new AbortController();

    async function loadProducts() {
      try {
        setStatus("loading");

        const response = await fetch("/api/products", {
          signal: controller.signal,
        });

        if (!response.ok) {
          throw new Error(`HTTP ${response.status}`);
        }

        const data = await response.json();
        setProducts(Array.isArray(data.items) ? data.items : []);
        setStatus("success");
      } catch (error) {
        if (error.name === "AbortError") return;
        setStatus("error");
      }
    }

    loadProducts();

    return () => controller.abort();
  }, []);

  if (status === "loading") return <p>Загрузка...</p>;
  if (status === "error") return <p>Не удалось загрузить товары</p>;
  if (products.length === 0) return <p>Товаров пока нет</p>;

  return products.map((product) => <ProductCard key={product.id} product={product} />);
}

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

Frontend обычно не должен знать, как backend хранит данные, какие таблицы использует и какие внутренние сервисы дергает. Ему важен публичный контракт: endpoint, метод, параметры, схема ответа, статусы и правила авторизации.

Если контракт стабилен, backend может менять внутреннюю реализацию без поломки интерфейса. Если контракт меняется без договоренности, frontend ломается даже при рабочем сервере. Например, поле user.name стало user.fullName, массив стал объектом, или null пришел там, где компонент ждал строку.

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

Не нужно превращать ответ на вопрос про API в сравнение всех подходов. Но полезно показать, что API не равен REST.

REST API обычно строится вокруг ресурсов и HTTP методов: GET получить, POST создать или выполнить действие, PUT заменить, PATCH частично обновить, DELETE удалить. GraphQL дает клиенту возможность запросить нужную форму данных через схему. WebSocket API подходит для двустороннего обмена в реальном времени, например для чата или live-уведомлений.

Для интервью достаточно такой формулировки: REST это популярный способ проектировать HTTP API, но API как понятие шире. Главное, чтобы между клиентом и сервером был понятный контракт и frontend корректно обрабатывал его поведение.

В ответе про API стоит аккуратно упомянуть безопасность. API часто работает с пользовательскими данными, платежами, профилями и внутренними действиями. Поэтому запросы идут по HTTPS, а доступ контролируется токенами, cookies, сессиями, OAuth или другими механизмами.

Для frontend особенно важна граница секретов. Нельзя класть приватный API key в код, который попадет в браузер. Пользователь может открыть DevTools, посмотреть network-запросы, bundle и переменные, которые доступны на клиенте.

Данные из API тоже остаются внешними данными. Текст можно рендерить как текст, а HTML из CMS или пользовательского поля нельзя вставлять в DOM без санитайза. Если авторизация построена на cookies, для изменяющих запросов важно учитывать CSRF: frontend и backend должны договориться про SameSite, CSRF token или другой защитный механизм.

Еще один важный нюанс: 401 и 403 не одно и то же. 401 обычно означает, что пользователь не прошел аутентификацию. 403 означает, что пользователь известен, но у него нет прав. В UI это разные реакции.

На интервью вам не нужно доказывать, что вы знаете все виды API. Лучше показать, что вы понимаете роль API как контракта и умеете думать про последствия для интерфейса.

Сильный короткий финал может звучать так:

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