Хорошая практика использования различных методов в REST API
В настоящее время я использую маршрут патча к / api / events /: id, который позволяет пользователю обновлять вхождение. Дело в том, что мне нужно будет обновить вхождения разными способами (один для обновления некоторых данных, один просто для изменения статуса и другой для обновления некоторых других данных). Каким будет лучший путь (как в хороших практиках) для проверки вхождения на примере? Я думал об использовании / api / events / validate /: id, когда дело доходит до проверки, но это действительно лучшая практика?
Большое спасибо, @SergioTulentsev;)
На самом деле архитектуре REST не важно, как вы структурируете URI, но важно то, что используются значимые имена отношений и типы носителей, в противном случае клиенты соединяются с API и, следовательно, ломаются, когда API развивается и изменяется. Читая ваш вопрос, я чувствую, что ваш ресурс, возможно, слишком велик и вы пытаетесь выполнить многие обязанности. Возможно, разделение его на более мелкие ресурсы может помочь вам в решении вашей проблемы.
Ответы 2
Проверка данных должна выполняться путем добавления аннотаций проверки java в bean-компонент, как показано ниже:
@NotNull
private String lastName;
@NotNull
private String firstName;
@NotNull
private LocalDate dateOfBirth;
@NotNull
private Integer siblings;
Мне очень жаль, но я спросил не об этом.
Нет, это не очень хорошая практика, не из-за URI (как упоминал выше Роман Воттнер, REST не заботится о том, как вы структурируете свои URI), а потому, что вы эффективно создаете метод RPC.
Есть ли причина, по которой PATCH для / api / событий /: id не отвечал с ошибкой 400 Bad Request и подробностями, если проверка не удалась?
У меня будут разные роли, и каждая роль будет выполнять свое действие с документом. Например, менеджер должен иметь возможность обновлять статус вхождения, поэтому у нас может быть маршрут только для этого конкретного патча, поскольку это действие отличается от обновления данных вхождения.
Роли и разрешения @ André являются внутренними и не должны открываться внешнему миру. Вы, конечно, можете возвращать разные ответы для разных пользователей / ролей в зависимости от имеющихся у них разрешений. Тем не менее, может быть важно отключить кеширование для этих ресурсов, поскольку промежуточный кеш может выполнять запросы к серверу, не предназначенные для определенных пользователей.
@ André, часть проблемы использования разных URL-адресов для разных действий состоит в том, что это усложняет инвалидацию кеша. например, без дополнительных усилий патч для /api/occurrences/validate/:id не сделает /api/occurrences/:id недействительным. Также с точки зрения семантики, ресурс, который вы изменяете, находится на /api/occurrences/:id, поэтому вам следует отправлять запросы PATCH. Если вам нужно поддерживать различные действия по модификации, я бы использовал дополнительный параметр, чтобы указать, какое действие выполняется.
@TomHoward Например, только менеджер может изменить статус события, но и менеджер, и секретарь могут изменить обычные данные события.
Итак, / api / событий / validate /: id будет использоваться для обновления обычных данных события, в то время как / api / событий / validate /: id будет обновлять только статус. Секретарь будет иметь доступ к / api / events /: id, но не к / api / events / validate /: id. Есть ли в этом смысл или мне следует поступить иначе?
Вы имеете в виду: «/ api / событий /: id будет использоваться для обновления обычных данных события, в то время как / api / событий / validate /: id будет обновлять только статус».
@ André Бизнес-действия, которые пользователь может предпринять для представления, возвращаемого сервером, должны быть найдены в наборе ссылок с осмысленными именами отношений ссылок. В вашем случае, когда и секретарю, и руководителю разрешено изменять данные, предоставьте этим пользователям ссылку на своего рода формулу, где они могут вводить данные и отправлять их в службу. На самом деле пользователей не интересует точный URI, но то, что данные передаются на сервер. В случае менеджера вы также можете добавить ссылку для изменения статуса события - это похоже на (HTML-) Web
@ André, кажется, Роман говорит о чем-то вроде github.com/kevinswiber/siren#actions-1