Как правильно искать вложенные ресурсы REST?

Question

[APsivenko]

Допустим у меня есть линк:
/api/v1/m/projects/{p_id}/sprints/{s_id}/tasks/{t_id}
Поддерживаются все CRUD операции.
Но как правильно обработать отсутствие родительских ресурсов? И правильно ли будет слать в ответ сообщение с ошибкой если не будет найден родительский ресурс.

Например:

1. Не найден проект - ошибка, проект не найден.
   
2. Проект найден, не найден спринт - ошибка, спринт не найден.
   

У меня пока решение одно - в сервисе искать по очереди ресурсы:

1. Найти проект по id.
   
2. Найти спринт по id и проекту.
   
3. Найти задание по id, проекту и спринту. (Ну или будет достаточно спринта и id).
   

UPDATE
Я имел в виду поиск задачи. Мне нужно пройтись по родительским ресурсам и проверить есть ли они.
Например:
Метод "Создать задание" делает по очереди:

1. Проверка на наличие проекта по id. Если нету - исключение.
   
2. Проверка на наличие спринта по id и проекту. Если нету - исключение.
   
3. Создание задания с заданным спринтом.
   

Answer 1

[Alex XYZ]

Такие проверки надо делать фильтрами. До вызова бизнес-логики.

Comments

[APsivenko]

А можно ли сделать это с помощью валидатора?

[Alex XYZ]

APsivenko: Если для одного случая, то наверное можно, но лично я не считаю такую обработку ошибок в целом хорошей практикой. Кроме того, вы не описали клиента этого сервиса, поэтому я пока не могу утверждать всё на 100%.

Answer 2

[Руслан Лопатин]

1. Сервис выкидывает исключение типа SprintNotFoundException, ProjectNotFoundException, TaskNotFoundException
2. Обработчик исключений (глобальный или для контроллера) выдаёт ошибку 404 с подробностями в теле ответа.

Хотя обычно достаточно исключения типа NotFoundException. Подробности (что именно не найдено) - содержатся в сообщении этого исключения.

Comments

[APsivenko]

Это я понимаю, меня интересует алгоритм метода. Например при создании задания нормально ли по очереди проверять наличие проекта и спринта. Я обновил вопрос для лучшего понимания.

[Руслан Лопатин]

Если используете реляционную базу данных, то самый надёжный вариант - это проверка внутри одной транзакции запросами типа SELECT...FOR UPDATE. Запрос может быть и один, кстати. А так - да, вполне рабочий подход

[APsivenko]

Руслан Лопатин: меня смущает то, что я хочу отдавать сообщение с ошибкой о отсутствии конкретного ресурса, а не самого последнего. И один выход - по очереди проверить все ресурсы.

[Руслан Лопатин]

Можно проверять существование каждого из трёх ресурсов одним составным SQL-запросом, если есть желание. Впрочем, большой разницы нет - один запрос или три.