Основы Back-end разработки: Фундамент серверной части

Введение в архитектуру: Как работают клиент-серверное взаимодействие и протокол HTTP

Добро пожаловать в курс «Основы Back-end разработки: Фундамент серверной части». Если вы когда-либо задумывались, что происходит «под капотом», когда вы нажимаете кнопку «Войти» в любимом приложении или вводите адрес сайта в браузере, вы попали по адресу.

Эта статья — первая ступень в понимании того, как устроен интернет. Мы не будем сразу писать сложный код. Сначала нам нужно разобраться с правилами игры и архитектурой, на которой держится весь веб.

Что такое Back-end и Frontend?

Любое современное веб-приложение можно разделить на две большие части:

Frontend (Клиентская часть) — это то, что видит пользователь. Красивые кнопки, анимации, формы ввода, текст и картинки. Это «лицо» сайта, которое работает в вашем браузере или смартфоне.
Back-end (Серверная часть) — это «мозг» и «память» приложения. Это скрытая от глаз часть, которая обрабатывает данные, сохраняет их в базы данных, проводит платежи и отправляет письма.

Чтобы понять, как они взаимодействуют, давайте представим поход в ресторан.

Аналогия с рестораном

Представьте, что вы пришли поужинать.

Вы (Клиент) — это пользователь с браузером (Frontend). Вы сидите за столиком и смотрите в меню.
Кухня (Сервер) — это Back-end. Там хранятся продукты (База Данных), там повара готовят блюда по рецептам (Логика приложения).
Официант — это связующее звено. Вы не идете на кухню сами, чтобы пожарить стейк. Вы даете заказ официанту, он несет его на кухню, ждет готовности и приносит вам еду.

В мире веба роль официанта выполняет протокол HTTP.

Клиент-серверная архитектура

В основе большинства веб-приложений лежит клиент-серверная архитектура. Это модель взаимодействия, где обязанности строго разделены.

Кто такой Клиент?

Клиент — это инициатор общения. Это программа, которая отправляет запрос. Чаще всего это:

Веб-браузер (Chrome, Safari, Firefox).
Мобильное приложение (Instagram, Telegram на вашем телефоне).
Другие серверы (да, серверы тоже могут быть клиентами друг для друга).

Кто такой Сервер?

Сервер — это мощный компьютер (или программа), который постоянно включен и ждет запросов от клиентов. Его задачи:

Принять запрос.
Понять, что от него хотят.
Выполнить действие (найти информацию, сохранить данные, посчитать что-то).
Отправить ответ обратно клиенту.

Протокол HTTP: Язык общения

Чтобы клиент и сервер понимали друг друга, они должны говорить на одном языке. Этот язык называется HTTP (HyperText Transfer Protocol — протокол передачи гипертекста).

HTTP — это набор правил, определяющий, как должны выглядеть сообщения (запросы и ответы). Это текстовый протокол, что означает, что все данные передаются в виде текста, который (при желании) можно прочитать глазами.

Жизненный цикл: Запрос и Ответ

Все общение в HTTP строится по схеме Request-Response (Запрос-Ответ).

Клиент формирует HTTP-запрос (Request) и отправляет его серверу.
Сервер обрабатывает запрос.
Сервер отправляет HTTP-ответ (Response).

Важно понимать: HTTP — это протокол без сохранения состояния (stateless). Это значит, что сервер не помнит вас между двумя разными запросами. Каждый запрос для него — как новый. Если вы хотите, чтобы сервер вас «узнал» (например, чтобы не вводить пароль каждый раз), используются дополнительные механизмы (cookies и сессии), о которых мы поговорим в следующих статьях.

Анатомия HTTP-запроса (Request)

Когда браузер обращается к серверу, он отправляет «письмо» определенного формата. Давайте разберем, из чего оно состоит.

Запрос состоит из трех основных частей:

Стартовая строка (Method + URL).
Заголовки (Headers).
Тело запроса (Body) — необязательно.

1. Метод и URL

URL (Uniform Resource Locator) — это адрес, куда мы стучимся. Например, https://google.com/search.

Метод — это глагол, который говорит серверу, что мы хотим сделать. Самые популярные методы:

Метод	Описание	Пример из жизни	Аналогия с рестораном
GET	Получить данные. Ничего не менять на сервере.	Открыть статью, загрузить картинку.	Попросить меню.
POST	Отправить новые данные для создания ресурса.	Регистрация, отправка комментария.	Сделать заказ.
PUT	Полностью обновить существующие данные.	Изменить информацию в профиле.	Попросить заменить блюдо.
DELETE	Удалить данные.	Удалить пост или фото.	Отменить заказ.

2. Заголовки (Headers)

Заголовки — это служебная информация, «метаданные». Они не видны пользователю на странице, но критически важны для браузера и сервера. Они выглядят как список Ключ: Значение.

Примеры заголовков запроса:

User-Agent: Mozilla/5.0... — «Привет, я браузер Chrome на Windows».
Accept-Language: ru-RU — «Я предпочитаю контент на русском языке».
Content-Type: application/json — «Я отправляю тебе данные в формате JSON».

3. Тело (Body)

Тело запроса нужно, когда мы передаем данные на сервер (например, при методе POST). Если вы заполняете форму регистрации, то ваши логин и пароль полетят именно в теле запроса. У метода GET тела обычно нет.

Анатомия HTTP-ответа (Response)

Сервер получил запрос, поработал и отправляет ответ. Ответ тоже имеет строгую структуру:

Стартовая строка (Версия HTTP + Код состояния).
Заголовки (Headers).
Тело ответа (Body).

Коды состояния (Status Codes)

Это трехзначные числа, которые сообщают результат операции. Вы наверняка видели 404. Коды делятся на классы:

1xx (Информационные): «Я получил запрос, продолжаю процесс».
2xx (Успех): Все прошло хорошо.
- 200 OK — Самый частый ответ. «Вот твои данные».
- 201 Created — «Я успешно создал то, что ты просил».
3xx (Перенаправление): «Ресурс переехал, иди по другому адресу».
- 301 Moved Permanently — Постоянный переезд.
4xx (Ошибка клиента): Вы (клиент) сделали что-то не так.
- 400 Bad Request — «Я не понял твой запрос».
- 401 Unauthorized — «Ты кто? Войди в систему».
- 404 Not Found — «Такой страницы не существует».
5xx (Ошибка сервера): Клиент молодец, но сервер сломался.
- 500 Internal Server Error — «У меня что-то упало внутри, прости».
- 502 Bad Gateway — Проблема связи между серверами.

Тело ответа

Это то, ради чего все затевалось. Если вы запрашивали веб-страницу, в теле придет HTML-код. Если вы запрашивали картинку — придет бинарный код картинки. Если данные для приложения — придет JSON.

Пример реального взаимодействия

Давайте соберем все вместе. Вы вводите в браузере habr.com и нажимаете Enter.

Браузер (Клиент) формирует запрос:

GET / HTTP/1.1
Host: habr.com
User-Agent: Chrome/90.0
Accept: text/html

Запрос летит через интернет к Серверу Habr.
Сервер видит метод GET и понимает, что нужно отдать главную страницу.

Сервер формирует ответ:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Server: nginx

<!DOCTYPE html>
<html>
<head>...</head>
<body>...</body>
</html>

Браузер получает код 200 OK, читает HTML из тела ответа и рисует вам страницу.

Заключение

Сегодня мы заложили первый камень в фундамент вашего понимания Back-end разработки. Мы выяснили, что:

Веб работает по модели Клиент-Сервер.
Общение происходит через протокол HTTP.
Клиент отправляет Запросы (Requests), а сервер шлет Ответы (Responses).
У каждого запроса есть Метод (цель), а у ответа — Код состояния (результат).

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

Выбор инструментов: Популярные языки программирования и серверные фреймворки

В предыдущей статье мы разобрали, как устроен «ресторан» веба: у нас есть Клиент (посетитель), Сервер (кухня) и HTTP (официант). Теперь пришло время заглянуть на саму кухню.

Когда вы решаете стать Back-end разработчиком, первый вопрос, который встает перед вами: «На чем писать код?». Если Frontend-разработчики фактически ограничены одним языком (JavaScript) и его вариациями, то в мире Back-end царит полное разнообразие. Python, Java, PHP, Go, C#, JavaScript (Node.js) — глаза разбегаются.

В этой статье мы разберем основные инструменты современной серверной разработки, поймем разницу между языком и фреймворком, и поможем вам определиться с выбором.

Язык vs Фреймворк: В чем разница?

Прежде чем обсуждать конкретные технологии, нужно понять два фундаментальных определения.

Язык программирования

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

Примеры: Python, Java, JavaScript, PHP.

Фреймворк (Framework)

Это набор готовых инструментов, библиотек и правил написания кода, написанных на конкретном языке.

Представьте, что вам нужно построить дом.

Язык — это ваши инструменты: молоток, пила, дрель. Вы можете построить дом с нуля, выпиливая каждую доску самостоятельно. Это долго и сложно, но дает полную свободу.
Фреймворк — это готовый каркас дома, бетонные блоки и заводские панели. Вам не нужно изобретать, как делать окно — вы берете готовый блок «Окно» и вставляете его. Это ускоряет работу в десятки раз.

Фреймворк — это не просто библиотека, это каркас, который диктует архитектуру вашего приложения. Как говорится: «Вы вызываете библиотеку, а фреймворк вызывает вас».

Сводная таблица для выбора

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

Язык	Основные фреймворки	Сложность изучения	Идеально подходит для...
Python	Django, FastAPI	Низкая	Стартапы, AI, быстрая разработка
JavaScript	Express, NestJS	Средняя	Fullstack, чаты, реал-тайм приложения
PHP	Laravel	Низкая	Фриланс, сайты контента, E-commerce
Java	Spring Boot	Высокая	Банки, крупные корпорации, надежность
Go	Gin, Echo	Средняя	Микросервисы, очень высокие нагрузки

Что такое Стек технологий?

Вы часто будете слышать слово «Стек» (Stack). Это набор технологий, которые используются вместе в одном проекте.

Например, популярный стек MERN:

MongoDB (База данных)
Express.js (Бэкенд фреймворк)
React (Фронтенд библиотека)
Node.js (Среда выполнения)

Выбирая язык, вы часто выбираете и стек, с которым будете работать.

Как выбрать свой первый язык?

Если вы только начинаете, не пытайтесь выучить всё сразу. Вот простой алгоритм выбора:

Хотите быстрый результат и легкий старт? Выбирайте Python или PHP. Вы напишете первый сайт уже через пару дней.
Уже знаете основы верстки и JavaScript? Выбирайте Node.js. Вам не придется учить новый синтаксис.
Мечтаете работать в крупном банке или корпорации? Готовьтесь к трудностям и учите Java.
Хотите быть на острие производительности? Смотрите в сторону Go.

Заключение

В Back-end разработке нет «лучшего» языка. Есть инструменты, подходящие под конкретную задачу. Молоток не лучше отвертки — он просто для другого.

В рамках этого курса мы будем рассматривать концепции, которые применимы ко всем этим языкам. Базы данных, API, безопасность и архитектура работают одинаково, независимо от того, пишете вы на Python или на Java.

В следующей статье мы перейдем от теории к практике и подготовим наше рабочее окружение, чтобы написать первые строчки кода.

Хранение данных: Основы проектирования и работы с базами данных SQL и NoSQL

Мы продолжаем наш путь в изучении Back-end разработки. В прошлых статьях мы разобрали, как клиент общается с сервером (ресторан и официант) и какие инструменты (языки и фреймворки) используются на «кухне». Но в нашей аналогии с рестораном остался один незакрытый вопрос: откуда повар берет продукты?

Повар не создает стейк из воздуха. Ему нужно пойти в холодильник или кладовую, взять нужные ингредиенты и только потом начать готовить. В мире веб-разработки этой «кладовой» является База Данных (БД).

Сегодня мы узнаем, как приложения запоминают информацию, почему нельзя просто хранить всё в текстовых файлах и в чем вечная битва между SQL и NoSQL.

Зачем нужна База Данных?

Представьте, что вы пишете приложение для заметок. Пользователь вводит текст «Купить молоко» и нажимает «Сохранить». Куда девается этот текст?

Если мы просто будем держать его в оперативной памяти сервера (в переменной внутри кода), то при первой же перезагрузке сервера (или если он «упадет» с ошибкой) все данные исчезнут. Оперативная память — это кратковременная память.

Нам нужно постоянное хранение (persistence). Мы могли бы записывать всё в обычный текстовый файл .txt на жестком диске сервера. Но представьте, что у вас миллион пользователей. Поиск одной заметки в гигантском текстовом файле займет вечность. А что, если два пользователя захотят записать что-то одновременно? Файл может повредиться.

Здесь на сцену выходят СУБД — Системы Управления Базами Данных. Это специальный софт, который умеет:

Надежно хранить данные на диске.
Быстро искать информацию (даже среди миллиардов записей).
Защищать данные от потери и несанкционированного доступа.

Два главных лагеря: SQL и NoSQL

Все современные базы данных делятся на два больших типа по способу организации информации: Реляционные (SQL) и Нереляционные (NoSQL).

1. Реляционные базы данных (SQL)

Это классика, проверенная десятилетиями (появились в 70-х годах). Слово «реляционный» происходит от английского relation — отношение (связь).

Как это устроено? Представьте себе обычные таблицы Excel. У вас есть строки и столбцы. Каждая таблица имеет строгое название и структуру.

Основные понятия:

Таблица (Table): Хранилище данных об одном типе объектов (например, таблица Users).
Строка (Row): Одна конкретная запись (один пользователь: Иван, 25 лет).
Столбец (Column): Атрибут объекта (Имя, Возраст, Email).
Первичный ключ (Primary Key): Уникальный номер (ID) каждой строки. Например, у Ивана ID = 1. Это нужно, чтобы отличать одного Ивана от другого.
Внешний ключ (Foreign Key): Ссылка на строку в другой таблице. Это то, что создает связи.

Пример: У нас есть таблица Users и таблица Orders. В таблице Orders мы не пишем имя заказчика снова. Мы просто пишем user_id = 1. Так база данных понимает, что этот заказ сделал Иван.

Язык SQL Чтобы общаться с такими базами, используется язык SQL (Structured Query Language — язык структурированных запросов). Он очень похож на обычный английский.

Пример запроса (найти всех пользователей старше 18 лет):

SELECT * FROM Users WHERE age > 18;

Популярные реляционные СУБД:

PostgreSQL — мощная, бесплатная, стандарт индустрии сейчас.
MySQL — самая популярная в мире, на ней работает WordPress.
SQLite — маленькая база данных, которая хранится в одном файле (используется в телефонах).

2. Нереляционные базы данных (NoSQL)

NoSQL (расшифровывается как Not Only SQL — не только SQL) набрали популярность с развитием социальных сетей и Big Data, когда данных стало слишком много, и они стали слишком разнородными для строгих таблиц.

Как это устроено? Здесь нет таблиц, строк и столбцов. Данные хранятся в более гибких форматах. Самый популярный тип NoSQL — Документоориентированные базы.

Представьте, что вместо аккуратных таблиц Excel у вас есть огромная коробка, куда вы сбрасываете папки с документами. В одной папке может лежать анкета с фото, в другой — только текст, в третьей — список покупок. Никакой строгой структуры.

Данные обычно хранятся в формате JSON (JavaScript Object Notation).

Пример записи в NoSQL (MongoDB):

{
  "name": "Ivan",
  "age": 25,
  "contacts": {
    "email": "ivan@example.com",
    "phone": "+79990000000"
  },
  "hobbies": ["football", "coding"]
}

Обратите внимание: мы можем вложить объект contacts внутрь пользователя. В SQL нам пришлось бы создавать для контактов отдельную таблицу.

Сравнение: SQL против NoSQL

Как выбрать, что использовать? Давайте сравним их.

Характеристика	SQL (Реляционные)	NoSQL (Нереляционные)
Структура	Строгая. Нужно заранее определить все поля.	Гибкая. Можно добавлять новые поля на лету.
Связи	Отлично работают со сложными связями.	Связи слабые или отсутствуют.
Масштабируемость	Вертикальная (нужен более мощный сервер).	Горизонтальная (можно добавить больше дешевых серверов).
Надежность (ACID)	Высокая. Гарантирует целостность транзакций.	Часто жертвуют строгой надежностью ради скорости.
Для чего лучше	Финансы, интернет-магазины, CRM-системы.	Соцсети, аналитика, игры, чаты, кэш.

«SQL — это как библиотека, где каждая книга стоит на своем месте по алфавиту. NoSQL — это как корзина для бумаг, куда вы быстро кидаете записки, чтобы потом их разобрать».

Основы проектирования БД (на примере блога)

Давайте спроектируем простую базу данных для блога, используя SQL подход, так как он учит мыслить структурно.

Нам нужно хранить:

Пользователей (авторов).
Статьи.

Шаг 1. Определяем сущности

У нас есть две сущности: User и Post.

Шаг 2. Определяем атрибуты (колонки)

User: id, username, email, password_hash.
Post: id, title, content, created_at, author_id.

Шаг 3. Определяем связи

Один пользователь может написать много статей. Это связь «Один-ко-Многим» (One-to-Many).

Чтобы связать их, мы добавляем в таблицу Post колонку author_id. В этой колонке будет храниться id пользователя из таблицы User.

CRUD-операции

Работа с любой базой данных сводится к четырем основным действиям, которые называют аббревиатурой CRUD:

Create (Создать) — INSERT
Read (Прочитать) — SELECT
Update (Обновить) — UPDATE
Delete (Удалить) — DELETE

Пример на языке SQL:

Создать пользователя:

INSERT INTO Users (username, email) VALUES ('Alex', 'alex@mail.com');

Найти статьи, которые написал Alex (предположим, его ID = 1):

SELECT title, content FROM Posts WHERE author_id = 1;

Обновить заголовок статьи:

UPDATE Posts SET title = 'Новый заголовок' WHERE id = 5;

Удалить статью:

DELETE FROM Posts WHERE id = 5;

Что такое Транзакции (ACID)?

Важное понятие в базах данных — это транзакция. Это последовательность действий, которая должна выполниться либо целиком, либо не выполниться вообще.

Пример: Перевод денег с карты на карту.

Списать 100 рублей у Алисы.
Зачислить 100 рублей Бобу.

Если на шаге 2 произойдет ошибка (выключат свет), деньги у Алисы спишутся, а Бобу не придут. Они исчезнут.

Чтобы этого не случилось, SQL базы данных поддерживают принцип ACID. Если хоть одна часть транзакции не прошла, база данных делает «откат» (Rollback) и возвращает всё как было до начала операции. Деньги Алисы вернутся на счет.

Заключение

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

Выбирайте SQL (PostgreSQL, MySQL), если у вас четкая структура данных и важны связи (пользователи, заказы, товары).
Выбирайте NoSQL (MongoDB), если структура данных постоянно меняется или вам нужна предельная скорость записи.
Выбирайте Redis, если нужно временно хранить данные для быстрого доступа (кэш).

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

Создание интерфейсов: Принципы построения REST API и работа с форматом JSON

Мы продолжаем наш курс по основам Back-end разработки. Давайте оглянемся назад: мы уже знаем, как работает интернет (HTTP), выбрали язык программирования (например, Python или JavaScript) и научились хранить данные в базе данных (SQL).

Но есть проблема. У нас есть «мозг» (код на сервере) и «память» (база данных), но как «руки» (клиентское приложение или сайт) могут взаимодействовать с ними? Как фронтенд-разработчик поймет, как именно попросить у вашего сервера список пользователей или сохранить новую статью?

Здесь на сцену выходит понятие API и его самый популярный архитектурный стиль — REST. Сегодня мы научимся строить мосты между программами.

Что такое API?

Аббревиатура API расшифровывается как Application Programming Interface (Программный интерфейс приложения).

Чтобы понять это, давайте посмотрим на розетку в вашей стене.

Вам не нужно знать, как устроена электростанция.
Вам не нужно знать, как проложены провода в стенах.
Вам просто нужно знать, что если у вас есть вилка правильной формы (интерфейс), вы получите электричество.

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

UI (User Interface) — это интерфейс для людей (кнопки, экраны).
API (Application Interface) — это интерфейс для машин (код, данные).

Когда вы нажимаете кнопку «Узнать погоду» в приложении, оно не измеряет температуру само. Оно стучится в API метеорологического сервиса и спрашивает: «Какая погода в Москве?». И API отвечает.

Архитектурный стиль REST

В начале 2000-х годов программисты поняли, что нужен единый стандарт общения в вебе. Рой Филдинг в своей диссертации описал принципы, которые назвали REST (Representational State Transfer — передача состояния представления).

REST — это не библиотека и не программа. Это набор правил и рекомендаций. Если ваш сервер соблюдает эти правила, его называют RESTful.

Главный принцип: Всё есть Ресурс

В REST мы перестаем думать глаголами («получить», «сохранить») и начинаем думать существительными («пользователь», «статья», «заказ»).

Каждая сущность в вашем приложении — это Ресурс. И у каждого ресурса должен быть свой уникальный адрес — URI (Uniform Resource Identifier).

Представьте, что мы делаем API для блога (как в прошлой статье про базы данных).

Плохой пример (RPC-стиль):

GET /getAllPosts
POST /createNewPost
GET /deletePost?id=5

Здесь URL перегружен действиями. Это неудобно поддерживать.

Хороший пример (REST-стиль):

/posts — это ресурс «Статьи».
/posts/5 — это конкретная статья с ID 5.
/users — это ресурс «Пользователи».

Обратите внимание: в URL мы используем только существительные во множественном числе. А как же сервер поймет, что мы хотим сделать (удалить, прочитать или обновить)? Для этого мы используем методы HTTP.

Магия HTTP-методов в REST

В первой статье мы говорили про методы HTTP. В REST API они обретают строгий смысл. Мы накладываем операции с базой данных (CRUD) на методы протокола HTTP.

Действие (CRUD)	Метод HTTP	URL (Пример)	Что происходит
Create (Создать)	POST	`/posts`	Создает новую статью. Данные передаются в теле запроса.
Read (Читать)	GET	`/posts`	Возвращает список всех статей.
Read (Читать)	GET	`/posts/5`	Возвращает одну статью с ID=5.
Update (Обновить)	PUT	`/posts/5`	Полностью перезаписывает статью №5.
Update (Обновить)	PATCH	`/posts/5`	Частично обновляет статью №5 (например, только заголовок).
Delete (Удалить)	DELETE	`/posts/5`	Удаляет статью №5.

Это делает ваш API предсказуемым. Любой разработчик в мире, увидев метод DELETE и адрес /users/10, поймет, что этот запрос удалит десятого пользователя, даже не читая документацию.

Формат данных: JSON

Хорошо, мы отправили запрос GET /users/1. Сервер нашел Ивана в базе данных. В каком виде он должен вернуть информацию клиенту?

Раньше популярным был формат XML (похож на HTML, с кучей тегов). Он был громоздким и сложным для чтения. Сейчас стандартом де-факто стал JSON (JavaScript Object Notation).

Что такое JSON?

Это текстовый формат обмена данными, основанный на синтаксисе объектов JavaScript. Но он настолько прост и удобен, что его используют во всех языках: Python, Java, C#, Go.

Основные правила JSON:

Данные хранятся в парах "ключ": значение.
Фигурные скобки {...} описывают объект.
Квадратные скобки [...] описывают массив (список).
Все ключи (названия полей) обязательно должны быть в двойных кавычках.

Типы данных в JSON

JSON поддерживает ограниченный набор типов данных:

Строка (String): "Привет"
Число (Number): 42 или 3.14
Булево значение (Boolean): true или false
Null: null (пустое значение)
Объект (Object): { ... }
Массив (Array): [ ... ]

Давайте посмотрим, как выглядит ответ нашего сервера для запроса GET /users/1:

{
  "id": 1,
  "username": "Ivan_Developer",
  "is_active": true,
  "stats": {
    "posts_count": 5,
    "rating": 4.8
  },
  "roles": ["author", "moderator"],
  "avatar_url": null
}

Это идеально читается и человеком, и машиной. Фронтенд (написанный на JavaScript) может превратить этот текст в живой объект одной командой.

Проектируем API для блога

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

1. Получение списка статей

Запрос: GET /api/v1/posts

Совет: Хорошей практикой считается указывать версию API (v1) в URL. Если вы кардинально измените структуру в будущем, вы сделаете v2, и старые приложения не сломаются.

Ответ (200 OK):

[
  {
    "id": 101,
    "title": "Основы REST",
    "author": "Alex"
  },
  {
    "id": 102,
    "title": "Как выучить Python",
    "author": "Maria"
  }
]

2. Создание новой статьи

Запрос: POST /api/v1/posts Тело запроса (Body):

{
  "title": "Моя первая статья",
  "content": "Всем привет, это текст статьи...",
  "author_id": 5
}

Ответ (201 Created): Сервер должен подтвердить создание и вернуть созданный объект (часто с присвоенным ID).

{
  "id": 103,
  "title": "Моя первая статья",
  "created_at": "2023-10-27T10:00:00Z"
}

3. Ошибка клиента

Что если клиент попытается получить статью, которой нет?

Запрос: GET /api/v1/posts/9999

Ответ (404 Not Found):

{
  "error": "Post not found",
  "code": 404
}

Важно использовать правильные HTTP-коды. Если вы вернете код 200 OK с текстом внутри {"error": "Ошибка"}, фронтенд-разработчик будет вас ненавидеть, потому что его программа будет думать, что запрос прошел успешно.

Вложенные ресурсы

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

В REST принято использовать вложенность:

GET /posts/5/comments — получить все комментарии к статье №5.
POST /posts/5/comments — добавить комментарий к статье №5.
DELETE /posts/5/comments/12 — удалить комментарий №12 у статьи №5.

Однако не стоит делать вложенность слишком глубокой (например, /posts/5/comments/12/likes/3). Это усложняет систему. Лучше сделать плоскую структуру, если это возможно.

Идемпотентность

Сложное слово, но простой смысл. Метод считается идемпотентным, если повторный идентичный запрос не меняет состояние сервера (или приводит к тому же результату).

GET — идемпотентен. Сколько бы раз вы ни запрашивали список статей, ничего на сервере не изменится.
DELETE — идемпотентен. Если вы удалили статью №5, первый запрос удалит её. Второй запрос вернет 404 (уже удалена), но состояние сервера останется тем же — статьи №5 нет.
PUT — идемпотентен. Если вы 10 раз отправите «Замени имя на Иван», имя останется «Иван».
POST — НЕ идемпотентен. Если вы 10 раз отправите запрос на создание статьи, у вас создастся 10 одинаковых статей.

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

Заключение

Сегодня мы разобрали, как сервер общается с внешним миром.

API — это интерфейс для программ.
REST — это стиль, где мы используем URL как адреса ресурсов, а HTTP-методы как действия.
JSON — это язык, на котором они обмениваются данными.

Теперь у нас есть почти всё для создания полноценного приложения. Но остался один критически важный вопрос: Безопасность. Как сделать так, чтобы Вася не мог удалить статью Пети? Как сервер понимает, кто именно отправляет запрос?

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

Финальные штрихи: Основы безопасности, аутентификации и деплоя приложения на сервер

Поздравляю! Вы прошли долгий путь. Мы начали с того, как работает интернет (HTTP), выбрали инструменты (языки и фреймворки), научились хранить данные (SQL) и создали язык общения между программами (API).

Казалось бы, наше приложение готово. Оно работает на вашем ноутбуке, вы можете создавать пользователей и писать статьи. Но готовы ли вы выпустить его в большой мир?

Если вы сделаете это прямо сейчас, ваше приложение, скорее всего, взломают за пару часов, а данные пользователей утекут в сеть. Кроме того, как вообще перенести код с вашего компьютера в интернет, чтобы он был доступен 24/7?

В этой финальной статье курса мы разберем три кита, на которых держится профессиональная разработка: Аутентификация, Безопасность и Деплой.

Кто ты и что тебе можно? (Аутентификация vs Авторизация)

В предыдущей статье мы создали API, который позволяет удалять статьи. Но сейчас любой, кто знает адрес /delete/post/5, может удалить статью. Нам нужно научить сервер различать пользователей.

В IT есть два похожих термина, которые новички часто путают:

Аутентификация (Authentication) — ответ на вопрос «Кто ты?». Это процесс проверки личности.
- Пример: Вы вводите логин и пароль. Сервер сверяет их и говорит: «Окей, ты — Иван».
Авторизация (Authorization) — ответ на вопрос «Что тебе можно?». Это проверка прав доступа.
- Пример: Иван хочет удалить статью. Сервер проверяет: «Иван — администратор? Нет. Значит, доступ запрещен».

Аутентификация — это когда вы показываете паспорт на проходной бизнес-центра. Авторизация — это когда ваш пропуск открывает дверь в офис, но не открывает дверь в кабинет директора.

Как сервер запоминает пользователя?

Мы помним, что протокол HTTP — stateless (без сохранения состояния). Это значит, что сервер забывает вас сразу после того, как отправил ответ. Как же тогда сайты помнят, что вы вошли в систему, когда вы переходите со страницы на страницу?

Есть два основных подхода:

1. Сессии (Sessions)

Это классический подход.

Вы вводите пароль.
Сервер создает в своей памяти запись: «Пользователь Иван сейчас онлайн, вот его временный ID сессии: abc-123».
Сервер отправляет этот ID вам в виде Cookie.
Теперь браузер автоматически прикрепляет эту Cookie к каждому вашему запросу.

Минус: Если у вас миллион пользователей, серверу нужно хранить миллион записей в памяти. Это сложно масштабировать.

2. Токены (JWT — JSON Web Tokens)

Это современный стандарт для REST API и мобильных приложений.

Вы вводите пароль.
Сервер не запоминает вас. Вместо этого он выписывает вам «цифровой пропуск» (Токен). В этом токене зашифрована информация: «Это Иван, пропуск действителен 1 час».
Сервер подписывает этот токен секретным ключом и отдает вам.
Вы храните токен у себя (в браузере или телефоне) и прикрепляете его к запросам.

Плюс: Серверу не нужно ничего помнить. Когда приходит запрос с токеном, сервер просто проверяет подпись: «Подпись моя? Да. Срок годности не истек? Нет. Проходи, Иван».

Основы безопасности: Как не стать жертвой хакеров

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

1. Никогда не храните пароли в открытом виде

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

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

Пример:

Пароль: 123456
Хеш (SHA-256): 8d969eef6ecad3c29a3a629280e686cf...

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

Чтобы усложнить жизнь хакерам, к паролю добавляют «Соль» (Salt) — случайную строку. Это делает хеш уникальным даже для одинаковых паролей.

2. Используйте HTTPS

HTTP передает данные открытым текстом. Если вы сидите в кафе с бесплатным Wi-Fi, злоумышленник может перехватить ваш трафик и прочитать пароли, которые вы отправляете.

HTTPS (S — Secure) шифрует данные. Даже если их перехватят, хакер увидит лишь бессмысленный набор символов.

3. Не доверяйте входящим данным (SQL Injection)

Представьте, что у вас есть код, который ищет пользователя по имени:

SELECT * FROM Users WHERE name = 'Введенное_Имя';

Если пользователь введет имя Ivan, все хорошо. А если хитрый хакер введет в поле имени такую строку: Ivan'; DROP TABLE Users; --

То запрос превратится в:

SELECT * FROM Users WHERE name = 'Ivan'; DROP TABLE Users; --';

База данных выполнит первую команду (найдет Ивана), а затем удалит таблицу со всеми пользователями. Это называется SQL-инъекция.

Решение: Всегда используйте специальные инструменты фреймворков (ORM) или подготовленные выражения (Prepared Statements), которые обезвреживают опасные команды.

Деплой: Выход в открытый космос

Вы написали код, настроили базу данных и защитили пароли. Но все это работает только на вашем localhost (локальном компьютере). Как сделать так, чтобы ваш друг из другого города мог зайти на ваш сайт?

Процесс переноса приложения на рабочий сервер называется Деплой (Deployment).

Что такое сервер?

Сервер — это просто компьютер, который подключен к интернету 24/7, имеет статический (постоянный) IP-адрес и очень мощное охлаждение. Вы не покупаете этот компьютер, вы арендуете его часть у облачных провайдеров (AWS, Google Cloud, DigitalOcean, Yandex Cloud).

Проблема «На моем компьютере работает»

Частая ситуация: вы написали код на Windows, использовали одну версию Python, а сервер работает на Linux и там другая версия. Приложение падает.

Чтобы решить эту проблему, была придумана технология Контейнеризации. Самый популярный инструмент — Docker.

Docker: Грузовые контейнеры для кода

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

Docker делает то же самое с кодом. Вы упаковываете:

Ваш код.
Язык программирования (например, Node.js).
Все библиотеки и зависимости.
Настройки операционной системы.

...в один Образ (Image).

Теперь вы можете запустить этот образ на любом компьютере, где есть Docker — будь то ваш ноутбук, сервер в Антарктиде или облако Amazon. И оно будет работать абсолютно одинаково.

Типичная схема работы (Pipeline)

Как выглядит современный процесс деплоя:

Разработка: Вы пишете код на своем компьютере.
Git: Вы отправляете код в репозиторий (GitHub/GitLab).
CI/CD (Continuous Integration/Delivery): Специальный робот видит новый код, автоматически запускает тесты (проверяет, ничего ли не сломалось) и собирает Docker-контейнер.
Сервер: Робот отправляет контейнер на ваш сервер и запускает его.
Nginx: На сервере стоит специальная программа — веб-сервер (например, Nginx). Она принимает запросы из интернета и перенаправляет их в ваше приложение.

Заключение курса

Мы прошли огромный путь в рамках курса «Основы Back-end разработки».

Мы разобрали Архитектуру: Клиент-Сервер и HTTP.
Мы выбрали Инструменты: Языки и Фреймворки.
Мы изучили Данные: SQL и NoSQL.
Мы построили Интерфейсы: REST API и JSON.
И сегодня мы узнали про Безопасность и Деплой.

Теперь у вас есть фундамент. Вы больше не смотрите на веб-сайты как на магию. Вы видите структуру: запросы, ответы, базы данных, токены.

Что делать дальше? Практиковаться. Выберите язык, который вам понравился, и попробуйте написать свой пет-проект (Pet Project). Это может быть список задач, блог или бот для Telegram. Ошибайтесь, гуглите, чините и снова ошибайтесь. Именно так становятся профессионалами.

Удачи в мире Back-end разработки! Код сам себя не напишет!

Введение в архитектуру: Как работают клиент-серверное взаимодействие и протокол HTTP

Введение в архитектуру: Как работают клиент-серверное взаимодействие и протокол HTTP

Что такое Back-end и Frontend?

Аналогия с рестораном

Клиент-серверная архитектура

Кто такой Клиент?

Кто такой Сервер?

Протокол HTTP: Язык общения

Жизненный цикл: Запрос и Ответ

Анатомия HTTP-запроса (Request)

1. Метод и URL

2. Заголовки (Headers)

3. Тело (Body)

Анатомия HTTP-ответа (Response)

Коды состояния (Status Codes)

Тело ответа

Пример реального взаимодействия

Заключение

Выбор инструментов: Популярные языки программирования и серверные фреймворки

Выбор инструментов: Популярные языки программирования и серверные фреймворки

Язык vs Фреймворк: В чем разница?

Язык программирования

Фреймворк (Framework)

Популярные связки «Язык + Фреймворк»

1. Python

2. JavaScript (Node.js)

3. Java

4. PHP

5. Go (Golang)

Сводная таблица для выбора

Что такое Стек технологий?

Как выбрать свой первый язык?

Заключение

Хранение данных: Основы проектирования и работы с базами данных SQL и NoSQL

Хранение данных: Основы проектирования и работы с базами данных SQL и NoSQL

Зачем нужна База Данных?

Два главных лагеря: SQL и NoSQL

1. Реляционные базы данных (SQL)

2. Нереляционные базы данных (NoSQL)

Сравнение: SQL против NoSQL

Основы проектирования БД (на примере блога)

Шаг 1. Определяем сущности

Шаг 2. Определяем атрибуты (колонки)

Шаг 3. Определяем связи

CRUD-операции

Что такое Транзакции (ACID)?

Заключение

Создание интерфейсов: Принципы построения REST API и работа с форматом JSON

Создание интерфейсов: Принципы построения REST API и работа с форматом JSON

Что такое API?

Архитектурный стиль REST

Главный принцип: Всё есть Ресурс

Магия HTTP-методов в REST

Формат данных: JSON

Что такое JSON?

Типы данных в JSON

Проектируем API для блога

1. Получение списка статей

2. Создание новой статьи

3. Ошибка клиента

Вложенные ресурсы

Идемпотентность

Заключение

Финальные штрихи: Основы безопасности, аутентификации и деплоя приложения на сервер

Финальные штрихи: Основы безопасности, аутентификации и деплоя приложения на сервер

Кто ты и что тебе можно? (Аутентификация vs Авторизация)

Как сервер запоминает пользователя?

1. Сессии (Sessions)

2. Токены (JWT — JSON Web Tokens)

Основы безопасности: Как не стать жертвой хакеров

1. Никогда не храните пароли в открытом виде

2. Используйте HTTPS

3. Не доверяйте входящим данным (SQL Injection)

Деплой: Выход в открытый космос

Что такое сервер?

Проблема «На моем компьютере работает»

Docker: Грузовые контейнеры для кода

Типичная схема работы (Pipeline)

Заключение курса