Как насчет использования переменных пути URI для HTTP POST?

Question

Я много искал, но не смог найти правильный ответ на мой вопрос, касающийся моих условий.
Я создаю REST API, и случай, который мне кажется пограничным,следующее:

- Я имею дело с двумя объектами, пользователями и ролями.Пользователю может быть назначено несколько ролей.
- Чтобы назначить Роль Пользователю, Роль должна быть уже в Базе данных.
- Чтобы назначить Роль Пользователю, требуется только «код».роли, которая является короткой строкой.
-Используемый сейчас шаблон пути URI:
--Пользователи: localhost: 8080 / api / users
--Given User: localhost: 8080 / api /users / {userId}
- Роли данного пользователя: localhost: 8080 / api / users / {userId} / role

Теперь, чтобы «связать» данного пользователя с данной ролью, двамне приходят в голову варианты.
-Первый, который звучит как лучшая практика в любом сценарии, отправляет данные сообщения в теле, возможно, в виде JSON.
-Другие, отправляет их через URI.и с пустым телом.Например, чтобы связать пользователя с идентификатором U001 с ролью R001, нужно будет опубликовать следующий uri, не отправляя данные в теле: localhost: 8080 / api / users / U001 / role / R001

в том, что я не возражаю против использования первого варианта, и он кажется лучшим и наиболее правильным, но в данном конкретном случае я не уверен, лучше ли отправлять почти пустое тело (поскольку оно содержит толькоидентификатор роли (очень короткая строка), отправив его на localhost: 8080 / api / users / U001 / role или пропустив тело, и просто отправив идентификатор роли через uri в качестве параметра пути, например localhost: 8080 / api / users/ U001 / ролей / R001

Спасибо всем заранее за вашу помощь.

Answer 1

Нет ничего плохого в том, чтобы указывать роль в URI.Ваша интуиция была на правильном пути.Я бы сделал это следующим образом.

PUT: locahost: 8080 / api / users / {userid} / role / {roleId}

И вот почему.

FIRST: Глагол PUT идемпотент .Другими словами (взято прямо из спецификации)

... побочные эффекты от N> 0 идентичных запросов такие же, как и для одного запроса.

Что, я полагаю, вы хотите в этом отношении?Вы не хотите, чтобы в вашем хранилище состояний было несколько записей для каждого экземпляра пользователя и роли.Пользователь должен чувствовать себя комфортно, выполняя один и тот же запрос PUT, не оказывая негативного влияния (добавляя дублирующиеся записи) на систему.

При выполнении того же действия с POST я ожидал, что для каждого запроса будет создана новая запись.

SECOND: глагол PUT должен идентифицировать конкретный ресурс.(взято прямо из спецификации)

... Запрос PUT идентифицирует объект, заключенный в запросе - пользовательский агент знает, для чего предназначен URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к некоторымдругой ресурс.Если сервер желает, чтобы запрос был применен к другому URI, он ДОЛЖЕН послать ответ 301 (перемещен постоянно);Затем пользовательский агент МОЖЕТ принять собственное решение относительно того, следует ли перенаправить запрос.

Что если роль R102 устареет, а R104 предпочтительнее?Верните 301 (перемещено навсегда) с заголовком (расположение: localhost: 8080 / api / users / {userid} / role / R104).

НАКОНЕЦ: Когда все работает хорошо.Вернуть 201 (Создано) при создании и 200 (Без содержимого) при каждом последующем запросе к одному и тому же URIЕсли они предоставляют роль, которой нет в системе, верните 501 (не реализовано).

Answer 2

Хмм - в этом случае - POST с 302 может быть немного грязным.

Почему бы не сделать очень простое 'PUT' / 'DELETE' с действительно предложенными URI?

С простым;Значение 20Х успешно выполнено, возможно, около 30Х указывает на то, что оно уже есть, а что-то еще не получилось?