Simple backend for a Java Spring blog

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

Основные пункты проекта:

Создание конечных точек для API:

Конечные точки будут позволять:

• l Добавление новых статей: Пользователи смогут добавлять статьи в базу данных.
• l Удаление существующих статей: Пользователи смогут удалять статьи по их ID.
• l Получение списка всех статей: Пользователи смогут просматривать полный список статей.
• l Получение детальной информации о конкретной статье: Пользователи смогут получать подробную информацию о выбранной статье на основе ее ID.
• l Оценка статей: Пользователи смогут оценивать статьи с помощью «пальца вверх» или «пальца вниз». Для предотвращения повторной оценки будет сохраняться session token пользователя.
• l Редактирование статей: Пользователи смогут редактировать свои статьи. При этом будет проверяться, соответствует ли session token пользователя ID автора статьи.

post_service

endpoints

/stories/article?id=id(int) GET return 200 json {articleText:str, articleRating:int, articleTitle:str, authorId:int}

/stories/article/create POST send json {articleText:str, articleTitle:str} return 200 OK

/stories/article/edit POST send json {articleText:str, articleTitle:str, articleId:int} return 200 OK

/stories/article/rate POST send json {articleId:int, vote:1/-1 (int)} return 200 json {articleRating}

/stories/article/delete POST send json {articleId:int} return 200 OK

/stories/article_get_list GET return json{[{articleRating:int, articleTitle:str, authorId:int}, {articleRating:int, articleTitle:str, authorId:int}, ...]}

Работа с MongoDB:

Статьи и их оценки будут храниться в базе данных MongoDB.

Структура каждой статьи будет включать:

• l Название: Название статьи.
• l Содержание: Основной текст статьи.
• l ID автора: Идентификатор автора статьи.
• l Оценка: Оценки пользователей (пальцы вверх/вниз) и session token пользователей, которые дали оценку.
• l Дата создания: Дата, когда статья была создана.

Система будет рассчитывать среднюю оценку на основе пользовательских голосов.

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

В куках пользователей будет храниться session token.

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

Реализация API:

Я буду использовать язык программирования Java и фреймворк Spring Boot, с помощью которого реализую REST API. Это позволит фронтенду взаимодействовать с бэкендом через HTTP-запросы (GET, POST, DELETE), получая данные о статьях, добавляя, удаляя и изменяя их.

По завершении проекта я представлю код Java с необходимыми классами и методами, а также подробную документацию к проекту.

Дополнительные детали по авторизации и валидации пользователя:

Авторизация и проверка авторства:

При каждом запросе от пользователя на сервер будет передаваться cookie, содержащий JSON Web Token (JWT). Этот токен будет подписан сторонним сервисом для обеспечения целостности данных.

JWT будет декодироваться на стороне сервера для получения информации о пользователе, включая его ID (id) и имя пользователя (username). Декодирование позволит извлечь содержимое токена, которое в закодированном виде представляет строку типа ergir543u8dfhudhuee333j.

После получения токена сервер отправит его на внешний микросервис авторизации для проверки подлинности. Это будет осуществляться через HTTP-запрос с использованием библиотеки request (или аналогичной). Запрос будет проходить между контейнерами напрямую, минуя взаимодействие с клиентской стороной.

Эндпоинт для проверки токена будет выглядеть как /users/validate?token=<токен>. При отправке запроса на этот адрес сервис авторизации подтвердит или опровергнет валидность токена.

Ожидаемый ответ от сервиса валидации:

• 1. 204 (No Content) — токен действителен, пользователь авторизован.
• 2. 401 (Unauthorized) — токен недействителен, доступ запрещен.

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

Каждый пользователь будет иметь:

• l ID пользователя (integer).
• l Username (текст).

Статья будет содержать:

• l ID статьи (integer).
• l ID автора (integer).
• l Username автора (возможно, для отображения).

Процесс валидации:

После получения JWT из cookie, сервер декодирует его для извлечения ID пользователя и имени пользователя.

Сервер отправляет токен на микросервис авторизации по заранее определенному эндпоинту (/users/validate) для проверки подлинности.

В случае успешной валидации (ответ 204), сервер разрешает пользователю выполнять действия, такие как редактирование статьи. При этом сервер сравнивает ID автора статьи с ID пользователя, извлеченным из токена.

Если валидация не проходит (ответ 401), сервер возвращает сообщение об ошибке, запрещая доступ к редактированию.

Технические детали:

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

Конфигурация эндпоинта для валидации (/users/validate) будет храниться в environment-переменных, чтобы обеспечить гибкость и безопасность при разворачивании приложения.