Skip to content

README.md

Latest commit

 

History

History
186 lines (134 loc) · 23.6 KB

README.md

File metadata and controls

186 lines (134 loc) · 23.6 KB
Raw

Map JSON — solution

Что сделано

📌 Что реализовано в проекте и какие требования задания уже покрыты 📖 Подробное описание результата без потери содержания 🧠 Что это означает на практике для сервера ✅ Итог
Реализован игровой веб-сервер game_server, который загружает конфигурацию карт из JSON-файла, предоставляет REST API на порту 8080, возвращает список карт, возвращает описание карты по её id, обрабатывает ошибки badRequest и mapNotFound, корректно завершает работу по SIGINT и SIGTERM Сервер поднимается как отдельное приложение, читает JSON-конфиг с описанием карт, запускает HTTP API и возвращает ответы в формате JSON с корректными статусами и типом содержимого Это уже не просто парсер JSON, а законченное backend-приложение с конфигом, моделью, request handler и HTTP-обвязкой Solution оформлен как полноценный игровой JSON API сервер

Что именно реализовано

🧩 Реализованная возможность сервера 📖 Полное описание поведения без потери содержания 🧠 Что это означает для API ✅ Итог
GET /api/v1/maps Возвращает JSON-массив: [ {"id":"map1","name":"Map 1"} ] Клиент получает краткий список карт Endpoint списка карт работает
Порядок карт Карты идут в том же порядке, что и в конфиге, потому что Game хранит их в std::vector<Map> и обход идёт по GetMaps() Порядок выдачи стабилен и соответствует данным конфига Порядок сохраняется
GET /api/v1/maps/{id} Возвращает полное JSON-описание карты: id, name, roads, buildings, offices Клиент получает полный объект карты Endpoint конкретной карты работает
Ошибка 404 Если карта не найдена: { "code":"mapNotFound", "message":"Map not found" } Сервер корректно сообщает, что карты нет mapNotFound реализован
Ошибка 400 Если путь начинается с /api/, но не подходит под нужные шаблоны: { "code":"badRequest", "message":"Bad request" } Сервер различает “карта не найдена” и “неправильный API-запрос” badRequest реализован
Content-Type Во всех успешных и ошибочных ответах используется: application/json Клиент всегда получает JSON как на успехе, так и на ошибке Тип содержимого единый и корректный
Сигналы Обрабатываются: SIGINT, SIGTERM Сервер умеет завершаться корректно Graceful shutdown реализован
Строка для тестов Перед RunWorkers(...) печатается: Server has started... Автотесты видят, что сервер готов к работе Требование тестов выполнено

Структура solution

solution/
├── CMakeLists.txt
├── conanfile.txt
├── README.md
├── data
│   └── config.json
└── src/
    ├── boost_json.cpp
    ├── http_server.cpp
    ├── http_server.h
    ├── json_loader.cpp
    ├── json_loader.h
    ├── main.cpp
    ├── model.cpp
    ├── model.h
    ├── request_handler.cpp
    ├── request_handler.h
    ├── sdk.h
    └── tagged.h

Что важно по дереву проекта

📂 Как понимать дерево проекта и что действительно важно для git и README 📖 Подробное объяснение без потери содержания 🧠 Практический смысл ✅ Итог
Полное дерево из tree может показывать каталог build/ и множество временных файлов сборки, но для README и для нормальной структуры solution важна именно рабочая часть проекта: CMakeLists.txt, conanfile.txt, README.md, data/, src/ Каталог build/ — это результат сборки и он не является исходной частью архитектуры solution, поэтому в README логично показывать только исходную структуру проекта, а не артефакты сборки README показывает нормальную проектную структуру, а git должен фиксировать исходники и нужные файлы, а не build-мусор В README оставляется чистое дерево solution без шума сборки

REST API

🌐 Endpoint REST API и его назначение 📖 Полное описание ответа без потери содержания 🧠 Что получает клиент ✅ Итог
GET /api/v1/maps Возвращает JSON-массив объектов с полями id и name Список всех карт в порядке конфига Endpoint списка работает
GET /api/v1/maps/{map_id} Возвращает полное JSON-описание карты Полная информация о карте Endpoint карты работает
404 + {"code":"mapNotFound","message":"Map not found"} Возвращается, если карта с данным id отсутствует Клиент получает понятную ошибку отсутствующей карты Ошибка 404 реализована
400 + {"code":"badRequest","message":"Bad request"} Возвращается, если API-путь начинается с /api/, но не соответствует поддерживаемым шаблонам Клиент получает понятную ошибку некорректного API-запроса Ошибка 400 реализована

Сборка

cd ~/cppbackend/sprint1/problems/map_json/solution
mkdir -p build
cd build
conan install .. --build=missing
cmake ..
cmake --build .

Запуск

▶️ Как запускать сервер после сборки 💻 Команда 📖 Что это означает ✅ Итог
Если есть конфиг в стандартном месте cd ~/cppbackend/sprint1/problems/map_json/solution/build и ./bin/game_server ../data/config.json Сервер стартует с локальным конфигом из каталога data Базовый способ запуска
Если нужен произвольный JSON-путь ./bin/game_server /путь/к/config.json Сервер может читать конфиг не только из стандартного каталога, но и по переданному пути Запуск гибкий

Важно

⚠️ Что обязательно нужно указать про старт сервера 📖 Полное объяснение без потери содержания 🧠 Почему это важно ✅ Итог
Перед запуском worker-потоков сервер печатает: Server has started... Это нужно для автотестов, чтобы они не начали проверку раньше времени Без этой строки тесты могут начать обращаться к серверу слишком рано Требование автопроверки выполнено

Как проверить вручную

Список карт

curl -i http://127.0.0.1:8080/api/v1/maps

Конкретная карта

curl -i http://127.0.0.1:8080/api/v1/maps/map1

Несуществующая карта

curl -i http://127.0.0.1:8080/api/v1/maps/unknown

Ожидаемо:

  • статус 404
  • JSON с code = "mapNotFound"

Неправильный API

curl -i http://127.0.0.1:8080/api/v1/unknown

Ожидаемо:

  • статус 400
  • JSON с code = "badRequest"

Проверка вручную в таблице

🧪 Что проверить через curl 💻 Команда 📖 Что должно получиться ✅ Итог
Список карт curl -i http://127.0.0.1:8080/api/v1/maps Успешный JSON-массив карт с полями id и name Список карт возвращается
Конкретная карта curl -i http://127.0.0.1:8080/api/v1/maps/map1 Успешный JSON с полным описанием карты Карта по id возвращается
Несуществующая карта curl -i http://127.0.0.1:8080/api/v1/maps/unknown Статус 404 и JSON с code = "mapNotFound" Ошибка карты работает
Неправильный API curl -i http://127.0.0.1:8080/api/v1/unknown Статус 400 и JSON с code = "badRequest" Ошибка badRequest работает

Ожидаемое поведение API

🌐 Сценарий запроса 📖 Полное ожидаемое поведение 🧠 Что это подтверждает ✅ Итог
GET /api/v1/maps Сервер возвращает JSON-массив карт в том же порядке, в каком они описаны в конфиге Порядок выдачи соответствует std::vector<Map> и GetMaps() Порядок сохранён
GET /api/v1/maps/{id} Сервер возвращает полное JSON-описание карты по её id Поиск карты по идентификатору работает Полный объект карты доступен
Неизвестная карта Сервер возвращает 404 и JSON { "code":"mapNotFound", "message":"Map not found" } Ошибки доменной логики различаются корректно 404 реализован правильно
Некорректный API-путь Сервер возвращает 400 и JSON { "code":"badRequest", "message":"Bad request" } Ошибки маршрутизации API различаются корректно 400 реализован правильно
Успешные и ошибочные ответы Во всех случаях Content-Type выставляется как application/json Формат ответов единый и ожидаемый JSON-API выдержан

Архитектурный смысл solution

🏗 Компонент архитектуры solution 📖 Что он делает в проекте 🧠 Почему он нужен ✅ Итог
json_loader.* Загружает конфигурацию карт из JSON-файла Отделяет чтение JSON от HTTP-слоя Конфиг загружается отдельно
model.* Хранит игровую модель, карты и связанные сущности Бизнес-логика отделена от транспорта Доменная модель выделена
request_handler.* Отвечает за обработку HTTP-запросов и формирование JSON-ответов API API-логика не смешивается с моделью и low-level сетью Слой API выделен
http_server.* Поднимает HTTP-сервер и сетевую инфраструктуру Асинхронная сетевая обвязка отделена от логики игры Сетевое ядро выделено
main.cpp Склеивает всё вместе: загрузку конфига, запуск сервера, сигналы, worker-потоки Точка входа приложения Сервер запускается как законченное приложение

Полезное замечание про пути

⚠️ Что важно помнить про переход в каталог solution 📖 Полное объяснение на основе фактического поведения терминала 🧠 Как правильно заходить в каталог ✅ Итог
Команда cd cppbackend/sprint1/problems/map_json/solution из ~/cppbackend не сработает, потому что путь будет искаться как вложенный ~/cppbackend/cppbackend/... Правильный путь из домашнего каталога выглядит как cd ~/cppbackend/sprint1/problems/map_json/solution, а если ты уже находишься в ~/cppbackend, то правильно делать cd sprint1/problems/map_json/solution Нужно учитывать текущую директорию, чтобы не дублировать cppbackend в пути Правильный рабочий путь: ~/cppbackend/sprint1/problems/map_json/solution

Итог

🏁 Финальный вывод по solution 📖 Полное описание без потери содержания 🧠 Что это означает ✅ Итог
Реализован игровой веб-сервер game_server, который загружает конфигурацию карт из JSON-файла, поднимает REST API на порту 8080, отдаёт список карт, отдаёт карту по id, различает badRequest и mapNotFound, печатает Server has started... перед RunWorkers(...) и корректно завершает работу по SIGINT и SIGTERM Проект собран как законченное solution-приложение с JSON loader, моделью, request handler и HTTP-сервером, а проверка вручную через curl подтверждает, что API ведёт себя по заданию Это полноценное решение задачи map_json, а не просто набор разрозненных функций Solution оформлен корректно и готов к сдаче