RESTful service and user maintenance - url structure and commands question

Question

I'm designing restful service and one of the entities to maintain - user accounts. I'm doing it in .NET and using membership provider.

Here is what I have:

/users/ GET - returns list of users

/users/ POST - can create or update multiple users (post array of User objects)

This POST won't matter if you updating or creating user

Problem I have: How do I create service to change password? Changing password is separate from updating users procedure. I'm thinking something like:

/users/{userName}/password POST - to change user password.

But then I have to pass different object here? (I use JSON)

Do you have any suggestion on how to layout URL? And should I really create another object? MembershipProvider requires old and new password to change

Answer 1

Well the question has to be whether we see the password as a resource in its own right, or not.

In my user dbs, I store all my passwords (salted and stretched) in their own table, so I can easily present the password as a separate resource. But just because you don't have that fine grained control doesn't mean you can't do the same - but I wouldn't consider implementing a GET for the password, ultimately you need an authentication service for that, which should follow some kind of protocol.

A rest service is free to represent its data however it wishes, with no real regard for the underlying structure so, given that, I think you're free to do it as a separate resource if it makes sense in your case.

You could include in your user data a uri to be used for changing the password. The client would have to know the type of data to send (so yes you will need a dedicated resource type to handle the change request), and that the uri should be triggered with a POST request.

Answer 2

If I understand your question, you'd like suggestions on how related to the Uri layout itself. The suggestions below is related specifically to designing a Uri that someone can use to change a password.

Never include any sensitive information in the clear in URIs, even if it comes over HTTPS, as that information may be written to log files on the server, or worse, recorded by analytics or monitoring software. Make sure sensitive information is sent as part of the body or part of the header.

Here are a couple of considerations why changing a password with a RESTfull service may require its own Uri:

1. Prevent accidental changes to a password when updating a user details.
2. Whenever this method changes, you may need additional security reviews as any defects therein that allows a anonymous user to change the password of an existing user will allow that anonymous user to hijack the account.
3. You may also want to include other additional security features like notifying a user that their password has changed and invalidate any OAuth tokens issues to applications. The membership provider is great, but doesn't provide this additional measures.
4. Since it is a different Uri you can monitor its usage and correlate it to IP Addresses allowing you to detect whether someone is trying to compromise a user account.

You can just PUT a data contract to https://example.com/users/{id}/password:

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

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

The latter assumes you'll authorize whether the client can actually perform this action. You may want to look at PUT vs POST in REST whether to use PUT or POST. In addition, the book RESTful Web Services and REST API Design Rulebook has been invaluable to me when designing RESTfull services, including Uri layout.