Основы 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-запроса, представленная в виде почтового отправления.

Анатомия 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.

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

Запрос летит через интернет к Серверу Habr.

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

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

Браузер получает код 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)

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

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

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

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

!Сравнение разработки на чистом языке и с использованием фреймворка.

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

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

1. Python

Фреймворки: Django, FastAPI, Flask.

Python — один из самых популярных языков в мире. Он славится своим простым и читаемым синтаксисом, который напоминает английский язык.

* Плюсы: Очень низкий порог входа, огромная экосистема, лидер в сфере искусственного интеллекта (AI) и машинного обучения. * Минусы: Медленнее компилируемых языков (как Java или Go) в выполнении сложных вычислений. * Для чего используют: Стартапы, Data Science проекты, быстрая разработка MVP (минимально жизнеспособного продукта).

Django — это мощный фреймворк «все включено». В нем сразу есть админ-панель, работа с базой данных, аутентификация пользователей. Идеален для новостных сайтов, интернет-магазинов.

FastAPI — современный, очень быстрый фреймворк для создания API. Набирает огромную популярность в последние годы.

2. JavaScript (Node.js)

Фреймворки: Express.js, NestJS.

Раньше JavaScript жил только в браузере. Но с появлением среды выполнения Node.js, JS пришел на сервер. Это создало уникальную ситуацию: один язык используется и на Frontend, и на Back-end.

* Плюсы: Возможность стать Fullstack-разработчиком, зная один язык. Огромная скорость обработки множества одновременных соединений (асинхронность). * Минусы: Может быть нестабильным при тяжелых математических вычислениях. * Для чего используют: Чаты, стриминговые сервисы, SPA (Single Page Applications), приложения реального времени.

Express.js — минималистичный и гибкий, стандарт де-факто для Node.js.

NestJS — более строгий фреймворк, вдохновленный Angular. Использует TypeScript (надстройка над JS), что делает код надежнее. Очень популярен в корпоративной разработке.

3. Java

Фреймворки: Spring Boot.

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

* Плюсы: Надежность, масштабируемость, многопоточность. Код, написанный 10 лет назад, будет работать и сегодня. * Минусы: Многословный код (нужно писать много строк для простых действий), потребляет много оперативной памяти. * Для чего используют: Банковский сектор, крупные корпоративные системы (Enterprise), высоконагруженные системы.

Spring Boot — это абсолютный король в мире Java-веба. Он упрощает настройку сложных Java-приложений, делая разработку комфортной.

4. PHP

Фреймворки: Laravel, Symfony.

PHP был создан специально для веба. Несмотря на критику в прошлом, современный PHP (версии 8+) — это быстрый и мощный инструмент. На PHP работает около 77% всех сайтов в интернете (включая WordPress).

* Плюсы: Самый простой и дешевый деплой (размещение сайта на сервере). Огромное количество готовых решений. * Минусы: Не подходит для долгоживущих соединений (например, веб-сокетов или чатов) так хорошо, как Node.js или Go. * Для чего используют: Сайты-визитки, блоги, интернет-магазины, фриланс-заказы.

Laravel — элегантный и выразительный фреймворк, который сделал PHP снова модным. Очень дружелюбен к новичкам.

5. Go (Golang)

Фреймворки: Gin, Echo (хотя часто пишут и без фреймворков).

Язык от Google. Он компилируемый (превращается в машинный код), как C++, но простой, как Python.

* Плюсы: Невероятная производительность. Создан специально для микросервисов и высоких нагрузок. * Минусы: Молодая экосистема (меньше готовых библиотек, чем у Java или Python). Специфический подход к обработке ошибок. * Для чего используют: Микросервисы, высоконагруженные системы (Uber, Twitch, Dropbox).

!Сравнительная характеристика языков программирования.

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

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

| Язык | Основные фреймворки | Сложность изучения | Идеально подходит для... | | :--- | :--- | :--- | :--- | | 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 лет):

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

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

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

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

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

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

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

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

Популярные NoSQL СУБД: * MongoDB — самая популярная документоориентированная база. * Redis — база данных типа «Ключ-Значение». Она хранит данные в оперативной памяти, поэтому работает молниеносно. Используется для кэширования. * Cassandra — используется Facebook и Netflix для хранения петабайтов данных.

Сравнение: 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:

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

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

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

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

Что такое Транзакции (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 отвечает.

!Визуализация 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:

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

!Древовидная структура JSON объекта, показывающая вложенность данных.

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

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

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

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

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

Ответ (200 OK):

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

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

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

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

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

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

Ответ (404 Not Found):

Важно использовать правильные 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)

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

Если пользователь введет имя Ivan, все хорошо. А если хитрый хакер введет в поле имени такую строку: 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 разработки! Код сам себя не напишет!