Для чего нужна папка api в FSD?

В Feature-Sliced Design приложение делится на слои: app, processes, pages, widgets, features, entities и shared. Слой api обычно размещается внутри shared или entities и отвечает за всё, что связано с общением с бэкендом: базовые HTTP-клиенты, конкретные эндпоинты, типы запросов и ответов, а также функции-обёртки над fetch или axios.

Зачем выделять отдельный слой

• Изоляция: компоненты не знают URL, заголовков и формата ответа — они вызывают готовую функцию.
• Переиспользование: один и тот же запрос можно использовать в разных фичах и виджетах.
• Тестируемость: api-функции легко мокать в тестах, не поднимая реальный сервер.
• Единая точка изменений: при смене бэкенда или формата правится только слой api.

Пример структуры

src/
  shared/api/
    client.ts        // базовый axios/fetch с interceptors
    endpoints.ts     // константы URL
  entities/user/
    api/
      getUser.ts     // функция запроса
      types.ts       // DTO и модели

Пример кода

// shared/api/client.ts
export const client = axios.create({
  baseURL: import.meta.env.VITE_API_URL,
});

// entities/user/api/getUser.ts
export async function getUser(id: string): Promise<User> {
  const { data } = await client.get(`/users/${id}`);
  return mapUserDto(data); // маппинг DTO в доменную модель
}

// features/profile/ui/Profile.tsx
const user = await getUser(userId); // UI не знает про axios

Такой подход позволяет менять транспорт (REST на GraphQL), не трогая компоненты, и держать бизнес-логику независимой от инфраструктуры.

Итог: слой api стоит применять всегда, когда приложение общается с сервером — он делает код чище, тестируемее и устойчивее к изменениям бэкенда.