Spring REST URI проверка существования - PullRequest
0 голосов
/ 08 апреля 2020

Давайте предположим, что простой RESTful API на основе Spring с некоторыми вложенными ресурсами.

  • A User - это root объект, созданный всеми для доступа к API
  • Каждый User может создать Posts, поэтому Post не может существовать без создателя
  • A User также может комментировать существующие Posts, поэтому Comment принадлежит Post

Для этого API я выбрал следующие маршруты RESTful:

  • /api/users для User
  • /api/users/{userId}/posts для Post
  • /api/users/{userId}/posts/{postId}/comments для Comment

О моем вопросе, должен ли я проверить, что родительские ресурсы существуют? Например, для запроса GET /api/users/2/posts/3/comments/7 я должен убедиться, что сущности User(2) и Post(3) также существуют? Должен ли я также убедиться, что сущности связаны друг с другом, а не используются какие-либо x произвольных существующих ресурсов?

Пример

@PostMapping("/api/users/{userId}/posts/{postId}/comments")
public void create(@PathVariable("userId") Long userId, @PathVariable("postId") Long postId, @RequestBody CommentPayload payload) {

    // userService.existsByIdWithPostId(userId, postId); ???

    commentService.createForPost(postId, payload);
}

Для создания комментарий в базе данных, userId совершенно неактуален, нужен только postId. Должен ли я по-прежнему убедиться, что пользователь с userId X существует и имеет сообщение с postId Y, или должен игнорировать его?

Если да, как я могу сделать это элегантно? Поскольку растущие запросы JPA / репозитория, такие как Optional<Comment> findByUserIdAndPostIdAndId(...), не кажутся решением ... Должна ли проверка затем выполняться в нескольких запросах? Включение всех идентификаторов родителей усложняет фактический запрос. Кроме того, идентификаторы должны проходить через все уровни (сервис, безопасность), что усложняет внутренний API.

1 Ответ

0 голосов
/ 08 апреля 2020

Краткий ответ: Да, вы должны проверить, существует ли родительский объект / 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 для более ясного объяснения

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...