Практический урок: пишем Rest Api с авторизацией и деплоем в облако

Зачем вообще разбираться в REST API и деплое

В 2025 году без API не живёт ни один сколько‑нибудь серьёзный сервис: мобильные приложения, маркетплейсы, платежи, даже «умный» чайник стучится в какой‑нибудь backend. Поэтому обучение разработке REST API с нуля онлайн стало почти обязательным этапом взросления разработчика. Важно не только уметь «наклепать эндпоинты», но и понимать, как устроена авторизация, почему без логов в проде жить нельзя и чем деплой в облако отличается от «запустил на локалке и забыл». Разберёмся на практическом примере, без лишней теории.

Что будем строить: минимальный, но честный проект

Практический урок: пишем REST API с авторизацией и деплоем в облако шаг за шагом - иллюстрация

Для практики возьмём реальный сценарий: небольшой сервис заметок с регистрацией пользователей, логином, защитой через токены и деплоем в облако. Такой API уже можно показывать на собеседованиях, а при желании допилить до коммерческого уровня и предлагать как разработка и деплой REST API в облако на заказ. Технологический стек возьмём популярный: Node.js + Express, база данных PostgreSQL, авторизация через JWT, а деплой в облачные сервисы сделаем на базе Docker и, скажем, Render или Railway — они проще для старта, чем голый Kubernetes.

Архитектура REST API: не просто «написать роуты»

Чтобы не утонуть в деталях, разобьём API на несколько логичных слоёв. Слой роутов отвечает за HTTP‑маршруты, контроллеры — за бизнес‑логику, а отдельный модуль авторизации занимается токенами и проверкой прав. Такой подход широко используется в курсах backend разработки REST API с авторизацией и позволяет позже без боли добавлять новые фичи. Логика простая: каждый слой знает только о своём наборе задач, а данные между ними «гуляют» в виде аккуратных объектов, а не случайных кусочков JSON.

Технический блок: пример структуры проекта

```bash
project/
src/
routes/
auth.routes.js
notes.routes.js
controllers/
auth.controller.js
notes.controller.js
services/
auth.service.js
notes.service.js
middlewares/
auth.middleware.js
db/
index.js
.env
Dockerfile
docker-compose.yml
package.json
```

Шаг 1. Проект и окружение: готовим фундамент

Начинаем с простой, но критичной штуки: окружение. Эксперты постоянно повторяют: «Не путайте dev и prod». На практике это значит — сразу вводим .env‑файл, где лежат секреты и настройки: порт, строка подключения к базе, JWT_SECRET. Для обучения это кажется бюрократией, но в реальных проектах утечка секретов в репозиторий на GitHub стоила компаниям десятки тысяч долларов и кучу репутационных потерь. Поэтому привычка всё конфигурировать через переменные среды — не из теории, а из боевого опыта.

Технический блок: минимальный запуск Express

```js
import express from 'express';
import dotenv from 'dotenv';
dotenv.config();

const app = express();
app.use(express.json());

app.get('/health', (req, res) => {
res.json({ status: 'ok', uptime: process.uptime() });
});

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => console.log(`API running on port ${PORT}`));
```

Шаг 2. Моделируем данные и подключаем базу

Любой REST API опирается на данные, поэтому сразу определяем сущности: User и Note. Эксперты советуют не усложнять модель на старте, а сфокусироваться на корректности связей и миграциях. Для PostgreSQL выбираем строкové id (UUID), храним пароли только в виде хеша, а заметки привязываем по user_id. Это позволяет быстро реализовать авторизацию и одновременно подготовить API к росту — например, добавлению тегов или шаринга заметок между пользователями, не ломая существующую структуру.

Технический блок: пример схемы таблиц

```sql
CREATE TABLE users (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
email TEXT UNIQUE NOT NULL,
password_hash TEXT NOT NULL,
created_at TIMESTAMP DEFAULT now()
);

CREATE TABLE notes (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES users(id),
title TEXT NOT NULL,
body TEXT,
created_at TIMESTAMP DEFAULT now(),
updated_at TIMESTAMP DEFAULT now()
);
```

Шаг 3. Авторизация: от теории к рабочему JWT

Настройка и внедрение авторизации для REST API под ключ — это не только «сделать логин», а продумать весь жизненный цикл токена. Мы реализуем регистрацию с хешированием пароля через bcrypt, вход с выдачей access‑токена на 15 минут и refresh‑токена на 7 дней. Такой подход используется в большинстве продакшн‑систем и закрывает базовые риски. Важный нюанс: никогда не возвращайте пользователю хеш пароля и не логируйте токены в чистом виде, иначе любой лог‑файл превращается в золотую жилу для злоумышленника.

Технический блок: базовая логика авторизации

```js
import jwt from 'jsonwebtoken';
import bcrypt from 'bcrypt';

const ACCESS_TTL = '15m';
const REFRESH_TTL = '7d';

export async function register(email, password) {
const hash = await bcrypt.hash(password, 10);
// сохранить пользователя в БД
}

export async function login(user, password) {
const ok = await bcrypt.compare(password, user.password_hash);
if (!ok) throw new Error('Invalid credentials');

const accessToken = jwt.sign({ sub: user.id }, process.env.JWT_SECRET, { expiresIn: ACCESS_TTL });
const refreshToken = jwt.sign({ sub: user.id, type: 'refresh' }, process.env.JWT_SECRET, { expiresIn: REFRESH_TTL });

return { accessToken, refreshToken };
}
```

Шаг 4. Защищённые эндпоинты и middleware

После того как авторизация заработала, нужно «закрыть» приватные маршруты. Здесь спасает middleware: маленькая функция, которая проверяет заголовок Authorization, декодирует токен и вешает user на объект запроса. Эксперты советуют делать middleware максимально тупым и независимым: никаких обращений к базе без необходимости, только валидация токена и разбор payload. Это упрощает тестирование и снижает вероятность странных побочных эффектов, которые в продакшене обычно всплывают в самый неудобный момент.

Технический блок: auth‑middleware

```js
export function authRequired(req, res, next) {
const header = req.headers.authorization;
if (!header?.startsWith('Bearer ')) {
return res.status(401).json({ message: 'Unauthorized' });
}

Шаг 5. Бизнес‑логика: CRUD для заметок

Теперь можно добавить основной функционал: создание, получение, обновление и удаление заметок только для авторизованного пользователя. Важно соблюдать семантику HTTP: POST для создания, GET для чтения, PATCH или PUT для обновления, DELETE для удаления. Для клиента это предсказуемое поведение и меньше сюрпризов. В реальной практике к этим базовым операциям быстро добавляются фильтры, поиск, пагинация, но фундамент остаётся тем же, что и в нашей учебной реализации API.

Технический блок: пример защищённого маршрута

```js
import { authRequired } from '../middlewares/auth.middleware.js';

app.post('/notes', authRequired, async (req, res) => {
const { title, body } = req.body;
const note = await notesService.create({
userId: req.user.id,
title,
body,
});
res.status(201).json(note);
});
```

Шаг 6. Облачный деплой: от Docker до сервиса

Когда локально всё работает, приходит время деплоя. Обучение DevOps деплой REST API в облачные сервисы обычно начинается с контейнеризации, и это не случайно: Docker даёт повторяемость окружения и избавляет от фраз «у меня на машине работает». Мы собираем образ, описываем порт и переменные среды, а затем грузим его в облако. Для старта подойдут Render, Railway, Fly.io или любой другой PaaS, где за вас уже настроены балансировщики, масштабирование и базовые метрики — этого хватит, чтобы уверенно пережить первые сотни пользователей.

Технический блок: простой Dockerfile

```Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV NODE_ENV=production
EXPOSE 3000
CMD ["node", "src/index.js"]
```

Шаг 7. Логи, мониторинг и типичные ошибки

Опытные разработчики сходятся в одном: «Если вы не видите, что происходит на проде, у вас нет продакшена». Минимальный набор — структурированные логи в JSON и хотя бы базовый alert на падение контейнера. Распространённая ошибка новичков — деплоить API без нормальной обработки исключений: в итоге любой странный входной параметр превращается в 500‑й статус без понятного описания. Лучше потратить час и сделать централизованный error‑handler, чем потом ночами разбираться, почему мобильное приложение внезапно перестало синхронизировать заметки у части пользователей.

Технический блок: обработка ошибок

```js
app.use((err, req, res, next) => {
console.error(err);
if (res.headersSent) return next(err);
res.status(err.status || 500).json({
message: err.publicMessage || 'Internal server error',
});
});
```

Пошаговый план для самостоятельной практики

Чтобы не распыляться, давайте соберём последовательность действий, которую реально выполнить за 1–2 вечера, если вы уже немного знакомы с JavaScript и Git.

Развернуть проект на Node.js, настроить .env и health‑check эндпоинт.
Поднять PostgreSQL (локально или в облаке), описать миграции для users и notes.
Реализовать регистрацию и логин, протестировать JWT через Postman или Insomnia.
Добавить middleware авторизации и CRUD‑операции для заметок.
Собрать Docker‑образ и задеплоить REST API в выбранный облачный сервис.

Такой маршрут по сложности близок к тому, что дают хорошие курсы backend разработки REST API с авторизацией, только здесь вы идёте своим темпом и сразу видите результат в продакшене, пусть и маленьком.