Краткий ответ: Да, вы должны проверить, существует ли родительский объект / root, и Да, вам нужно определить отношения между сущностями
Длинный ответ:
Тот факт, что Пост не может быть создан без пользователя, его не нужно проверять по структуре URL. URL только для уточнения , какой ресурс запрашивается . Проверка должна быть сделана непосредственно в коде. Проверка существования записи не требует дополнительных усилий и методов, и это из-за связи между сущностями.
Когда вы добавляете сообщение для пользователя, используя /users/{userId}/posts
API, вам нужно добавить сообщение в post-list пользователя с id=[userId]
, поэтому вы вызываете связанный метод репозитория для извлечения пользовательской записи (например, findById
), что само по себе является проверкой существования пользователя с помощью id=[userId]
. Причина, если репозиторий возвращает ноль, вы знаете, что пользователь не существует
Для разработки хорошего, эффективного и понятного API следуйте этому простому правилу:
Если к ресурсу можно обращаться по отдельности , он должен иметь базовый c URL-адрес как / [entity], в противном случае используйте шаблон parent-child (как, например, у вас для сообщений).
Обратите внимание, что это правило не может работать все Время и много раз вам нужно настраивать API и изменять его, чтобы сделать его более эффективным.
Итак, если пользователь может видеть сообщения других пользователей, вы должны разработать API следующим образом:
/users
[запросы на сущность пользователя] /posts
[запросы на сущность сообщения]
Затем для запроса на определенные сообщения пользователя c вам следует используйте /users/{userId}/posts
для создания нового поста или его чтения, а для запроса по конкретным c комментариям поста вы должны использовать /posts/{postId}/comments
.
Как я понимаю, дизайн вашего приложения вам не нужен /comments
потому что все комментарии относятся к постам и должны б Доступ к нему связан с соответствующей записью (как выше). Если к комментариям можно обращаться по отдельности (например, иметь страницу со списком всех комментариев, не заботясь о связанных с ними сообщениях), то вам потребуется /comments
API для более ясного объяснения