Лабораторная работа №1. Web-сервис и API. JSON / XML

1. Теория

1.0. Цель работы

Сформировать у обучающегося системное понимание принципов построения web-сервисов и API:

где находится клиент и сервер;
как устроено взаимодействие по протоколу HTTP;
какие методы используются для работы с ресурсами;
чем отличаются web-сайт, web-приложение и web-сервис;
как представляются данные в форматах JSON и XML.

Закрепить навык архитектурного описания системы через модель:

Client → Server → Database

и демонстрацию типового REST-взаимодействия.

1.1. Ключевые понятия: клиент, сервер, база данных

Клиент

Клиент — сторона, инициирующая HTTP-запрос и отображающая результат пользователю.

Варианты клиента:

браузер (Chrome, Firefox, Edge и др.);
мобильное приложение;
desktop-приложение;
другое серверное приложение (при интеграции через API).

Функции клиента:

формирование запроса;
отправка HTTP-запроса;
получение ответа;
обработка и отображение данных.

Сервер

Сервер — приложение, принимающее HTTP-запросы и формирующее ответы.

Типовая структура:

web-сервер (Nginx, Apache);
backend-приложение (Node.js/Express, Python/FastAPI, Java/Spring, C#/.NET и др.);
возможная микросервисная архитектура.

Функции сервера:

маршрутизация запросов;
выполнение бизнес-логики;
валидация данных;
обращение к базе данных;
формирование JSON/XML-ответа.

База данных (Database)

База данных — система хранения данных, используемая сервером.

Примеры:

реляционные СУБД: PostgreSQL, MySQL;
NoSQL: MongoDB;
in-memory: Redis (кэш).

Назначение:

хранение сущностей предметной области (users, orders, courses и т.д.);
обеспечение целостности и сохранности данных;
выполнение операций чтения/записи.

1.2. HTTP: модель взаимодействия

HTTP — протокол клиент-серверного обмена.

Общая схема:

Client → HTTP Request → Server → HTTP Response → Client

Основные HTTP-методы

GET — получение ресурса.
POST — создание нового ресурса.
PUT — полная замена ресурса.
PATCH — частичное обновление ресурса.
DELETE — удаление ресурса.

Основные статус-коды

200 OK — успешный запрос.
201 Created — ресурс создан.
400 Bad Request — ошибка запроса.
401 Unauthorized — требуется авторизация.
403 Forbidden — доступ запрещён.
404 Not Found — ресурс не найден.
500 Internal Server Error — ошибка сервера.

1.3. REST как архитектурный стиль

REST (Representational State Transfer) — подход к проектированию API, при котором:

каждый объект — это ресурс;
ресурсы адресуются через URL;
используются стандартные HTTP-методы;
ответы содержат представление ресурса (обычно JSON);
структура API единообразна и предсказуема.

Пример REST-ресурса:

GET    /api/orders
GET    /api/orders/15
POST   /api/orders
PATCH  /api/orders/15
DELETE /api/orders/15

1.4. Форматы представления данных

HTML

Назначение: отображение интерфейса.
Ориентирован на визуальное представление.
Используется браузером.

XML

Универсальный формат структурированных данных.
Строгий синтаксис.
Используется для обмена и интеграций.

XHTML

HTML, записанный по строгим правилам XML.
Требует обязательного закрытия тегов.
В современном web используется редко.

JSON

Формат представления данных в виде объектов и массивов.
Лёгкий, компактный, читаемый.
Де-факто стандарт для REST API.

1.5. Web-сайт, Web-приложение, Web-сервис

Тип	Основная цель	Интерактивность	API
Web-сайт	Представление информации	Низкая	Обычно нет
Web-приложение	Работа с данными и бизнес-логикой	Высокая	Есть
Web-сервис	Предоставление API другим системам	Может отсутствовать UI	Основной продукт

2. Задание

Цель

Проанализировать выбранное web-приложение и описать его как систему:

Client → Server → Database

Продемонстрировать:

архитектуру;
REST-взаимодействие;
формат данных;
HTTP-запрос и JSON-ответ.

2.1. Выбор объекта анализа

Выбрать одно web-приложение:

интернет-магазин;
LMS;
сервис бронирования;
ServiceDesk;
доставка / логистика;
иное (по согласованию).

Требование: система должна иметь сетевое взаимодействие (запросы/ответы).

2.2. Аналитический разбор

В отчёте указать:

Где находится клиент.
Где расположен сервер.
Какие данные передаются (минимум 4 сущности).
Какие HTTP-методы используются (минимум 3).

2.3. Архитектурная схема

Построить одну из схем:

C4-контекст (упрощённый);
блок-схему:

User → Client → Server → Database

Если есть — добавить внешние сервисы (платёж, почта и др.).

2.4. Примеры REST-взаимодействия (минимум 2)

Описать:

Сценарий чтения (GET).
Сценарий изменения данных (POST/PUT/PATCH/DELETE).

Для каждого указать:

URL;
метод;
параметры;
статус-код;
краткое описание ответа.

2.5. Таблица сравнения HTML / XML / XHTML

Составить таблицу по критериям:

назначение;
строгие правила;
закрывающие теги;
области применения;
читаемость человеком / обработка машиной.

2.6. Пример HTTP-запроса

Привести пример:

метод;
URL;
заголовки (Content-Type или Accept);
тело запроса (если применимо).

Формат — raw HTTP или curl.

2.7. Пример JSON-ответа

Пример должен содержать:

объект или массив;
минимум 5 полей;
вложенный объект или массив.

2.8. Аналитический вывод

1–2 страницы:

логика архитектуры;
обоснование, почему это web-приложение;
основные ресурсы;
анализ сильных/слабых сторон API.

3. Итоговая задача

«Интерактивный анализ API выбранного web-приложения»

3.1. Мини-каталог API

Сформировать каталог 4–6 ресурсов (например: users, orders, courses).

Для каждого указать:

назначение;
минимум 2 операции (метод + URL);
основные поля запроса/ответа.

3.2. Сценарий “UI → API → DB”

Описать один бизнес-сценарий:

действие пользователя;
HTTP-запрос;
обработка на сервере;
обращение к БД;
JSON-ответ;
обновление UI.

3.3. Сценарии ошибок (минимум 2)

ошибка валидации (400);
ошибка доступа (401/403) или не найдено (404).

Для каждого указать:

причину;
статус-код;
пример JSON-ошибки.

3.4. Для выполнения требуется

Шаблон отчёта.
Вариант задания в ЛМС.
Оформление по методическим указаниям.
Ссылка на репозиторий.

3.5. Запрет

❗ Запрещается использование систем искусственного интеллекта для выполнения лабораторной работы.

4. Контрольные вопросы

Чем GET отличается от POST?
Что означает 404?
Что такое REST-ресурс?
Почему JSON чаще используется, чем XML?
В чём различие web-приложения и web-сервиса?

5. Чек-лист для самопроверки

Баллы	Критерии
10	Полный анализ, схема, REST-примеры, HTTP-запрос, JSON-ответ, таблица сравнения, аргументированный вывод
8–9	Незначительные неточности
6–7	Частичная проработка
<6	Нет архитектурной логики
0	Работа не сдана или выполнена с ИИ

6. Шаблон отчёта

👉 Скачать шаблон отчёта