#11-Правка черновика

'#99. Черновики : draft';

'Tools_DraftController_actionUpdateHtml';

'#layouts_templates_updateHtml';

Правка кода HTML в тексте

<p>Мы уже разобрались, как устроены фронтенд и бэкенд, как работает клиент-серверная модель, где хранятся данные. Но остался важный вопрос: <strong>как именно фронтенд и бэкенд обмениваются информацией?</strong> Какой язык они используют для общения?</p>
<p>Ответ: через <strong>API (Application Programming Interface)</strong>, а конкретнее &ndash; через <strong>REST API</strong>. Это стандартный способ, которым пользуется большинство современных веб-приложений.</p>
<p>Если вы когда-нибудь планируете заниматься веб-разработкой или просто хотите понимать, как устроены сайты изнутри &ndash; эта статья для вас. Разберём всё простым языком, с примерами из жизни.</p>
<h2>Что такое API?</h2>
<p><strong>API (Application Programming Interface)</strong> &ndash; это набор правил и инструментов, которые позволяют одной программе взаимодействовать с другой.</p>
<p>Можно сравнить API с:</p>
<h3>Аналогия с рестораном (снова!)</h3>
<p>Представьте:</p>
<ul>
<li><strong>Вы (клиент)</strong> &ndash; хотите поесть, но не можете зайти на кухню и сами готовить. Есть правила.</li>
<li><strong>Меню</strong> &ndash; это интерфейс (API). В меню написано, что можно заказать, в каком формате (суп, основное блюдо, десерт), какие параметры указать (размер порции, степень прожарки).</li>
<li><strong>Официант</strong> &ndash; это посредник, который принимает ваш заказ и относит на кухню. Вы не общаетесь напрямую с поварами.</li>
<li><strong>Кухня (бэкенд)</strong> &ndash; готовит блюдо по вашему заказу и отдаёт официанту.</li>
<li><strong>Официант приносит готовое блюдо</strong> &ndash; вы получаете результат.</li>
</ul>
<p>Точно так же работает API:</p>
<ul>
<li><strong>Фронтенд (клиент)</strong> &ndash; хочет получить данные, но не имеет прямого доступа к базе данных.</li>
<li><strong>API</strong> &ndash; описывает, какие запросы можно отправлять, в каком формате, что вернётся в ответ.</li>
<li><strong>HTTP-запрос</strong> &ndash; официант, который доставляет запрос на сервер.</li>
<li><strong>Бэкенд</strong> &ndash; обрабатывает запрос, обращается к базе данных, выполняет логику.</li>
<li><strong>HTTP-ответ</strong> &ndash; возвращает данные фронтенду в структурированном виде (обычно JSON).</li>
</ul>
<h3>Зачем нужен API?</h3>
<ul>
<li><strong>Разделение ответственности</strong> &ndash; фронтенд занимается отображением, бэкенд &ndash; логикой и данными. Каждый делает своё.</li>
<li><strong>Безопасность</strong> &ndash; фронтенд не имеет прямого доступа к базе данных. Всё через API, где можно контролировать права доступа.</li>
<li><strong>Универсальность</strong> &ndash; один API могут использовать разные клиенты: веб-сайт, мобильное приложение, другие сервисы.</li>
<li><strong>Обновления без простоя</strong> &ndash; можно обновить фронтенд или бэкенд независимо, если API остаётся неизменным.</li>
</ul>
<h2>Что такое REST?</h2>
<p><strong>REST (Representational State Transfer)</strong> &ndash; это архитектурный стиль для построения API. Это не протокол и не технология, а набор принципов, соглашений, как должен быть организован API.</p>
<p>REST API &ndash; самый популярный способ построения веб-API сегодня. Почему? Потому что он:</p>
<ul>
<li><strong>Простой</strong> &ndash; легко понять и использовать</li>
<li><strong>Стандартизированный</strong> &ndash; работает поверх HTTP, который все знают</li>
<li><strong>Гибкий</strong> &ndash; подходит для любых задач</li>
<li><strong>Масштабируемый</strong> &ndash; легко добавлять новые функции</li>
</ul>
<h2>Основные принципы REST</h2>
<h3>1. Клиент-серверная архитектура</h3>
<p>Клиент (фронтенд) и сервер (бэкенд) разделены. Клиент не знает, как устроен сервер внутри, а сервер не знает, как клиент отображает данные. Они общаются только через API.</p>
<h3>2. Stateless (без сохранения состояния)</h3>
<p>Каждый запрос от клиента к серверу должен содержать всю необходимую информацию. Сервер не помнит предыдущие запросы.</p>
<p><strong>Пример:</strong></p>
<p><strong>Неправильно (с состоянием):</strong></p>
<pre>Запрос 1: "Авторизуй меня как Иван"
Запрос 2: "Покажи мои заказы" (сервер помнит, что ты Иван)</pre>
<p><strong>Правильно (без состояния):</strong></p>
<pre>Запрос 1: "Авторизуй меня как Иван" &rarr; получить токен
Запрос 2: "Покажи заказы пользователя с токеном XYZ123"</pre>
<p>Каждый запрос самодостаточен. Это упрощает масштабирование &ndash; любой сервер может обработать любой запрос.</p>
<h3>3. Кэшируемость</h3>
<p>Ответы сервера должны явно указывать, можно ли их кэшировать (сохранять временно). Это ускоряет работу &ndash; повторные запросы берутся из кэша, а не идут на сервер.</p>
<h3>4. Единообразный интерфейс</h3>
<p>API должен быть последовательным и предсказуемым. Если один endpoint (точка входа) работает определённым образом, все остальные должны работать похоже.</p>
<h3>5. Ресурсы и их представления</h3>
<p>В REST всё вращается вокруг <strong>ресурсов</strong>. Ресурс &ndash; это любая сущность: пользователь, товар, заказ, статья.</p>
<p>Каждый ресурс имеет:</p>
<ul>
<li><strong>Уникальный адрес (URI)</strong> &ndash; путь к ресурсу</li>
<li><strong>Представление</strong> &ndash; формат данных (обычно JSON)</li>
</ul>
<h2>Структура REST API: URL и методы HTTP</h2>
<p>REST API строится на основе HTTP и использует его методы для операций с ресурсами.</p>
<h3>HTTP-методы (глаголы)</h3>
<ul>
<li><strong>GET</strong> &ndash; получить данные (чтение)</li>
<li><strong>POST</strong> &ndash; создать новый ресурс</li>
<li><strong>PUT</strong> &ndash; полностью заменить существующий ресурс</li>
<li><strong>PATCH</strong> &ndash; частично обновить ресурс</li>
<li><strong>DELETE</strong> &ndash; удалить ресурс</li>
</ul>
<h3>Структура URL (endpoint)</h3>
<p>URL в REST API обычно строится по схеме:</p>
<pre>https://api.example.com/{коллекция}/{идентификатор}</pre>
<p><strong>Примеры:</strong></p>
<ul>
<li><code>/users</code> &ndash; коллекция всех пользователей</li>
<li><code>/users/123</code> &ndash; конкретный пользователь с ID 123</li>
<li><code>/products</code> &ndash; все товары</li>
<li><code>/products/456</code> &ndash; товар с ID 456</li>
<li><code>/orders</code> &ndash; все заказы</li>
<li><code>/orders/789/items</code> &ndash; позиции в заказе 789</li>
</ul>
<h3>CRUD-операции</h3>
<p><strong>CRUD</strong> &ndash; это аббревиатура основных операций с данными:</p>
<ul>
<li><strong>C</strong>reate &ndash; создать</li>
<li><strong>R</strong>ead &ndash; прочитать</li>
<li><strong>U</strong>pdate &ndash; обновить</li>
<li><strong>D</strong>elete &ndash; удалить</li>
</ul>
<p>REST API идеально подходит для CRUD:</p>
<table border="1" cellpadding="5">
<tbody>
<tr>
<th>Операция</th>
<th>HTTP-метод</th>
<th>URL</th>
<th>Описание</th>
</tr>
<tr>
<td>Получить всех</td>
<td>GET</td>
<td>/users</td>
<td>Список всех пользователей</td>
</tr>
<tr>
<td>Получить одного</td>
<td>GET</td>
<td>/users/123</td>
<td>Данные пользователя 123</td>
</tr>
<tr>
<td>Создать</td>
<td>POST</td>
<td>/users</td>
<td>Создать нового пользователя</td>
</tr>
<tr>
<td>Обновить</td>
<td>PUT</td>
<td>/users/123</td>
<td>Заменить данные пользователя 123</td>
</tr>
<tr>
<td>Частично обновить</td>
<td>PATCH</td>
<td>/users/123</td>
<td>Изменить отдельные поля</td>
</tr>
<tr>
<td>Удалить</td>
<td>DELETE</td>
<td>/users/123</td>
<td>Удалить пользователя 123</td>
</tr>
</tbody>
</table>
<h2>Формат данных: JSON</h2>
<p>REST API обычно использует <strong>JSON (JavaScript Object Notation)</strong> для передачи данных. Это текстовый формат, который легко читается и людьми, и машинами.</p>
<h3>Пример JSON:</h3>
<pre>{
  "id": 123,
  "name": "Иван Иванов",
  "email": "ivan@example.com",
  "registered_at": "2024-01-15",
  "is_active": true,
  "orders_count": 5
}</pre>
<p>JSON поддерживает:</p>
<ul>
<li><strong>Объекты</strong> &ndash; <code>{ "key": "value" }</code></li>
<li><strong>Массивы</strong> &ndash; <code>[ "item1", "item2" ]</code></li>
<li><strong>Строки</strong> &ndash; <code>"текст"</code></li>
<li><strong>Числа</strong> &ndash; <code>123</code>, <code>45.67</code></li>
<li><strong>Булевы значения</strong> &ndash; <code>true</code>, <code>false</code></li>
<li><strong>Null</strong> &ndash; <code>null</code></li>
</ul>
<h2>Примеры REST API-запросов</h2>
<p>Давайте разберём конкретные примеры, как фронтенд общается с бэкендом через REST API.</p>
<h3>Пример 1: Получить список товаров</h3>
<p><strong>Запрос (фронтенд отправляет):</strong></p>
<pre>GET /api/products HTTP/1.1
Host: example.com
Accept: application/json</pre>
<p><strong>Ответ (бэкенд возвращает):</strong></p>
<pre>HTTP/1.1 200 OK
Content-Type: application/json

{
  "products": [
    {
      "id": 101,
      "name": "Ноутбук Dell",
      "price": 50000,
      "in_stock": true
    },
    {
      "id": 102,
      "name": "Мышь Logitech",
      "price": 1500,
      "in_stock": true
    }
  ],
  "total": 2
}</pre>
<h3>Пример 2: Получить конкретный товар</h3>
<p><strong>Запрос:</strong></p>
<pre>GET /api/products/101 HTTP/1.1
Host: example.com</pre>
<p><strong>Ответ:</strong></p>
<pre>HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 101,
  "name": "Ноутбук Dell",
  "description": "15 дюймов, 16 ГБ RAM, 512 ГБ SSD",
  "price": 50000,
  "category": "Электроника",
  "in_stock": true,
  "quantity": 15
}</pre>
<h3>Пример 3: Создать нового пользователя (регистрация)</h3>
<p><strong>Запрос:</strong></p>
<pre>POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "name": "Пётр Петров",
  "email": "petr@example.com",
  "password": "securepass123"
}</pre>
<p><strong>Ответ:</strong></p>
<pre>HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/456

{
  "id": 456,
  "name": "Пётр Петров",
  "email": "petr@example.com",
  "created_at": "2024-11-22T10:30:00Z"
}</pre>
<p>Код <code>201 Created</code> означает, что ресурс успешно создан. Заголовок <code>Location</code> указывает URL нового ресурса.</p>
<h3>Пример 4: Обновить данные пользователя</h3>
<p><strong>Запрос (изменить только email):</strong></p>
<pre>PATCH /api/users/456 HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer abc123token

{
  "email": "newemail@example.com"
}</pre>
<p><strong>Ответ:</strong></p>
<pre>HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 456,
  "name": "Пётр Петров",
  "email": "newemail@example.com",
  "updated_at": "2024-11-22T11:00:00Z"
}</pre>
<p>Обратите внимание на заголовок <code>Authorization</code> &ndash; это токен авторизации. Без него сервер не позволит изменить данные пользователя.</p>
<h3>Пример 5: Удалить товар из корзины</h3>
<p><strong>Запрос:</strong></p>
<pre>DELETE /api/cart/items/789 HTTP/1.1
Host: example.com
Authorization: Bearer abc123token</pre>
<p><strong>Ответ:</strong></p>
<pre>HTTP/1.1 204 No Content</pre>
<p>Код <code>204 No Content</code> означает успешное удаление. Тело ответа пустое &ndash; ничего возвращать не нужно.</p>
<h3>Пример 6: Ошибка &ndash; товар не найден</h3>
<p><strong>Запрос:</strong></p>
<pre>GET /api/products/999999 HTTP/1.1
Host: example.com</pre>
<p><strong>Ответ:</strong></p>
<pre>HTTP/1.1 404 Not Found
Content-Type: application/json

{
  "error": "Product not found",
  "message": "Товар с ID 999999 не существует"
}</pre>
<h2>Коды статусов HTTP в REST API</h2>
<p>REST API использует стандартные HTTP-коды для обозначения результата запроса:</p>
<h3>2xx &ndash; Успех</h3>
<ul>
<li><strong>200 OK</strong> &ndash; запрос выполнен успешно, вот данные</li>
<li><strong>201 Created</strong> &ndash; ресурс успешно создан</li>
<li><strong>204 No Content</strong> &ndash; успешно выполнено, но нечего возвращать (обычно DELETE)</li>
</ul>
<h3>3xx &ndash; Перенаправление</h3>
<ul>
<li><strong>301 Moved Permanently</strong> &ndash; ресурс навсегда переехал на новый URL</li>
<li><strong>304 Not Modified</strong> &ndash; данные не изменились, используй кэш</li>
</ul>
<h3>4xx &ndash; Ошибка клиента</h3>
<ul>
<li><strong>400 Bad Request</strong> &ndash; неправильный формат запроса</li>
<li><strong>401 Unauthorized</strong> &ndash; требуется авторизация</li>
<li><strong>403 Forbidden</strong> &ndash; доступ запрещён (даже с авторизацией)</li>
<li><strong>404 Not Found</strong> &ndash; ресурс не найден</li>
<li><strong>409 Conflict</strong> &ndash; конфликт (например, email уже зарегистрирован)</li>
<li><strong>422 Unprocessable Entity</strong> &ndash; данные не прошли валидацию</li>
</ul>
<h3>5xx &ndash; Ошибка сервера</h3>
<ul>
<li><strong>500 Internal Server Error</strong> &ndash; что-то сломалось на сервере</li>
<li><strong>502 Bad Gateway</strong> &ndash; проблема с промежуточным сервером</li>
<li><strong>503 Service Unavailable</strong> &ndash; сервер временно недоступен</li>
</ul>
<h2>Авторизация в REST API</h2>
<p>Не все данные должны быть доступны всем. Как сервер понимает, кто отправил запрос?</p>
<h3>1. Токены (Token-based)</h3>
<p>Самый популярный способ:</p>
<ol>
<li>Пользователь авторизуется (логин + пароль)</li>
<li>Сервер возвращает токен (случайная строка, например: <code>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...</code>)</li>
<li>Фронтенд сохраняет токен (обычно в localStorage браузера)</li>
<li>Каждый последующий запрос отправляется с этим токеном в заголовке:
<pre>Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...</pre>
</li>
<li>Сервер проверяет токен и понимает, кто это</li>
</ol>
<h3>2. JWT (JSON Web Token)</h3>
<p>Специальный формат токена, который содержит закодированную информацию о пользователе. Сервер может декодировать токен и сразу понять, кто это, без обращения к базе данных.</p>
<h3>3. API Keys</h3>
<p>Для сервисов, которыми пользуются другие приложения (не люди). Выдаётся постоянный ключ:</p>
<pre>Authorization: ApiKey sk_live_1234567890abcdef</pre>
<h2>Pagination: работа с большими списками</h2>
<p>Что если в базе 10 000 товаров? Вернуть их все сразу &ndash; медленно и нерационально. Используется <strong>пагинация (постраничный вывод)</strong>.</p>
<p><strong>Пример запроса:</strong></p>
<pre>GET /api/products?page=2&amp;limit=20</pre>
<p>Параметры:</p>
<ul>
<li><code>page=2</code> &ndash; вторая страница</li>
<li><code>limit=20</code> &ndash; по 20 товаров на странице</li>
</ul>
<p><strong>Ответ:</strong></p>
<pre>{
  "products": [...20 товаров...],
  "page": 2,
  "limit": 20,
  "total": 10000,
  "pages": 500
}</pre>
<h2>Фильтрация и сортировка</h2>
<p><strong>Фильтрация:</strong></p>
<pre>GET /api/products?category=electronics&amp;price_max=30000&amp;in_stock=true</pre>
<p>Вернёт товары из категории "Электроника" дешевле 30 000₽, которые есть в наличии.</p>
<p><strong>Сортировка:</strong></p>
<pre>GET /api/products?sort=price&amp;order=asc</pre>
<p>Вернёт товары, отсортированные по цене по возрастанию.</p>
<h2>REST API vs GraphQL vs gRPC</h2>
<p>REST &ndash; не единственный способ построения API. Есть альтернативы:</p>
<h3>GraphQL</h3>
<p>Клиент запрашивает только те поля, которые нужны. Один endpoint вместо множества. Гибче, но сложнее.</p>
<h3>gRPC</h3>
<p>Бинарный протокол, очень быстрый. Используется для внутреннего общения между микросервисами. Для веба неудобен.</p>
<p>Для большинства веб-проектов REST остаётся оптимальным выбором: простой, понятный, проверенный временем.</p>
<h2>Главное из статьи</h2>
<ul>
<li><strong>API</strong> &ndash; интерфейс для взаимодействия между программами</li>
<li><strong>REST</strong> &ndash; архитектурный стиль для построения API поверх HTTP</li>
<li><strong>Принципы REST:</strong> клиент-сервер, stateless, кэшируемость, единообразие, ресурсы</li>
<li><strong>HTTP-методы:</strong> GET (чтение), POST (создание), PUT/PATCH (обновление), DELETE (удаление)</li>
<li><strong>JSON</strong> &ndash; стандартный формат данных в REST API</li>
<li><strong>Коды статусов:</strong> 2xx &ndash; успех, 4xx &ndash; ошибка клиента, 5xx &ndash; ошибка сервера</li>
<li><strong>Авторизация</strong> &ndash; через токены (JWT) или API Keys</li>
<li><strong>Пагинация, фильтрация, сортировка</strong> &ndash; для работы с большими объёмами данных</li>
</ul>
<p>Теперь у вас есть прочная теоретическая база: вы понимаете типы сайтов, фронтенд и бэкенд, клиент-серверную модель, базы данных и REST API. Это подготовка к практике &ndash; когда мы начнём разбирать реальные примеры, вы уже будете знать основы. Но даже в практических статьях мы продолжим углублять теорию, разбирая конкретные технологии и архитектурные решения.</p>

Краткое название: Что такое REST API: как общаются фронтенд и бэкенд

Полное название Что такое REST API: как общаются фронтенд и бэкенд

Черновик Редактировать название и описание

Название

Стандартный редактор Смотреть

Полное название и описание

Полное название (Заголовок)

Описание

Как правило описание должно иметь около 150 знаков. Оно используется для заполнения мета-тега Description веб-страницы.
Сейчас используется - 0 символов

Описание скопировано!

Описание вставлено!