RESTful сервис и обслуживание пользователей - вопрос структуры URL и команд

Question

Я разрабатываю спокойный сервис и одну из сущностей для обслуживания - учетные записи пользователей.Я делаю это в .NET и использую членство провайдера.

Вот что у меня есть:

/ users / GET - возвращает список пользователей

/ users / POST - может создавать или обновлять несколько пользователей (массив записей)объектов пользователя)

Этот POST не будет иметь значения, если вы обновляете или создаете пользователя

У меня проблема: Как создать службу для изменения пароля?Смена пароля отличается от процедуры обновления пользователей.Я думаю что-то вроде:

/ users / {userName} / password POST - чтобы сменить пароль пользователя.

Но тогда мне нужно передать другой объект здесь?(Я использую JSON)

Есть ли у вас какие-либо предложения по компоновке URL?И должен ли я действительно создать еще один объект?MembershipProvider требует старый и новый пароль для изменения

Answer 1

Ну, вопрос в том, видим ли мы пароль как ресурс самостоятельно или нет.

В моей пользовательской базе данных я храню все свои пароли (соленые и растянутые) в отдельной таблице, поэтому я могу легко представить пароль в качестве отдельного ресурса. Но то, что у вас нет такого тонкого контроля, не означает, что вы не можете сделать то же самое - но я бы не стал реализовывать GET для пароля, в конечном счете, для этого вам понадобится служба аутентификации, которая должна следовать некоторым вид протокола.

Служба отдыха может свободно представлять свои данные, как пожелает, без реального учета базовой структуры, поэтому, учитывая, что, я думаю, вы можете сделать это как отдельный ресурс, если это имеет смысл в вашем случае.

Вы можете включить в свои данные пользователя uri, который будет использоваться для смены пароля. Клиент должен знать тип данных для отправки (так что да, вам понадобится выделенный тип ресурса для обработки запроса на изменение), и что URI должен запускаться с помощью запроса POST.

Answer 2

Если я понимаю ваш вопрос, вы хотели бы получить предложения о том, как это связано с самим макетом Uri. Приведенные ниже предложения относятся конкретно к разработке Uri, который кто-то может использовать для изменения пароля.

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

Вот несколько соображений, почему для смены пароля с помощью службы RESTfull может потребоваться собственный Uri:

1. Предотвращение случайных изменений пароля при обновлении данных пользователя.
2. Всякий раз, когда изменяется этот метод, вам могут потребоваться дополнительные проверки безопасности, поскольку любые дефекты, которые позволяют анонимному пользователю изменить пароль существующего пользователя, позволят анонимному пользователю взломать учетную запись.
3. Вы также можете включить другие дополнительные функции безопасности, такие как уведомление пользователя об изменении его пароля и аннулирование любых проблем с маркерами OAuth для приложений. Поставщик членства хорош, но не предоставляет эти дополнительные меры.
4. Поскольку это другой Uri, вы можете отслеживать его использование и соотносить его с IP-адресами, что позволяет вам определить, пытается ли кто-то взломать учетную запись пользователя.

Вы можете просто ПОСТАВИТЬ контракт данных на https://example.com/users/{id}/password:

[DataContract]
public class ChangePassword
{
   [DataMember]
   public string OldPassword { get; set; }

   [DataMember]
   public string NewPassword { get; set; }
}

Последний предполагает, что вы разрешите, может ли клиент фактически выполнить это действие. Вы можете посмотреть PUT против POST в REST , использовать ли PUT или POST. Кроме того, книга Веб-службы RESTful и Правила разработки REST API была для меня неоценима при разработке служб RESTfull, включая макет Uri.