Домашнее задание к занятию «2.3. Spring Web MVC»

В качестве результата пришлите ссылки на ваши GitHub-проекты в личном кабинете студента на сайте netology.ru.

Важно: ознакомьтесь со ссылками, представленными на главной странице репозитория с домашними заданиями.

Важно: если у вас что-то не получилось, то оформляйте Issue по установленным правилам.

Как сдавать задачи

1. Создайте на вашем компьютере Maven-проект
2. Инициализируйте в нём пустой Git-репозиторий
3. Добавьте в него готовый файл .gitignore
4. Добавьте в этот же каталог остальные необходимые файлы
5. Сделайте необходимые коммиты
6. Создайте публичный репозиторий на GitHub и свяжите свой локальный репозиторий с удалённым
7. Сделайте пуш (удостоверьтесь, что ваш код появился на GitHub)
8. Ссылку на ваш проект отправьте в личном кабинете на сайте netology.ru

Migration

Легенда

Первая задача достаточно простая: вам нужно смигрировать ваше приложение на сервлетах, написанное в предыдущих ДЗ на Spring Web MVC с Embed Tomcat.

Задача

Создайте новый проект на базе Spring MVC и Embed Tomcat и перенесите реализованную в предыдущих ДЗ функциональность.

Ваш контроллер должен выглядеть именно так, как в лекции:

@RestController
@RequestMapping("/api/posts")
public class PostController {
  private final PostService service;

  public PostController(PostService service) {
    this.service = service;
  }

  @GetMapping
  public List<Post> all() {
    return service.all();
  }

  @GetMapping("/{id}")
  public Post getById(@PathVariable long id) {
    return service.getById(id);
  }

  @PostMapping
  public Post save(@RequestBody Post post) {
    return service.save(post);
  }

  @DeleteMapping("/{id}")
  public void removeById(long id) {
    service.removeById(id);
  }
}

Обратите внимание, что вся функциональность (CRUD), реализованная до этого, должна по-прежнему работать.

Результат

В качестве результата пришлите ссылку на ваш GitHub проект в личном кабинете студента на сайте netology.ru.

Данные не удаляются*

Важно: данная задача не является обязательной

Легенда

Самое плохое, что можно сделать с пользовательскими данными - это безвозвратно их удалить (они потом всегда звонят с просьбой восстановить и утверждают, что они-то точно ничего сами не удаляли). Поэтому чаще всего их не удаляют, а помечают на удаление (т.е. добавляют какое-то поле, например, removed).

Для простоты мы будем считать, что /api/posts - это API для клиентов, где они не смогут реализовать "восстановление" удалённых постов и даже просмотреть удалённые посты. Для этого будет отдельное API (позже).

Соответственно, получается, что removeById всего лишь выставляет это поле. Но это не всё, работа остальных методов тоже кардинально меняется:

• all возвращает все посты, кроме тех, у которых выставлен флаг removed
• getById возвращает пост только если у него не выставлен флаг removed, в противном случае кидает NotFoundException*
• save обновляет существующий пост только если у него не выставлен флаг removed, в противном случае кидает NotFoundException*

Примечание*: здесь нет идеального решения, разные люди могут вам говорить, что так можно, так нельзя и т.д. Мы же лишь скажем, что любая категоричность - это всегда плохо и вы должны понимать, что бывает по-разному, всё зависит от того, какое решение примет проектировщик API или команда.

Единственный вопрос остаётся со статус кодами. По логике, NotFoundException должен приводить к статус коду 404. Изучите документацию на @ResponseStatus и подумайте, как её применить для выставления статуса кода 404 при возникновении указанного нами Exception'а.

Подсказка

Использовать её нужно в формате @ResponseStatus(code = HttpStatus.NOT_FOUND), при этом, конечно же, импортировать и ResponseStatus и HttpStatus.

Задача

Создайте Pull Request с описанной функциональностью к проекту из первой задачи (Migration).

Решение по тому, на каком именно слое реализовать данную логику - остаётся за вами. Скажем лишь, что это точно не Controller.

Обратите внимание, что вся функциональность (CRUD), реализованная до этого, должна по-прежнему работать.

Результат

В качестве результата пришлите:

1. Ссылку на ваш Pull Request в личном кабинете студента на сайте netology.ru
2. Обоснование, почему вы реализовали логику именно в том слое, в котором реализовали