Comment 2 for bug 843075

PROPOSAL:
PUT is idempotent (preferably no side effects) and allows the client to control the URI.
POST is not idempotent and determines the returned object's URI
Both can be used for updates or creates.

We've been trying to keep the username as the identifier of the users, but that's looking like a goal e cannot achieve while supporting backend pluggability and all use cases (such as the ability to change a user's name).

New Assumptions:
- we'll use a string identifier (id) as a locator for users
- the backend may choose to use the username for that (but it then must not allow changes to the name)

#partial update on user (consider if-match ETAG or if-unmodified - but not core yet)
POST /users/uid
    {username: newuniqueid, other data...}
    200 OK - this is an update
    403 if username=uid in backend

#create user
POST /users/
    {username: uniquename, other data...}
    returns loc with uid
        /users/uuid

GET /users/uid
GET /users/?username=username
- username and uid could be the same (backend decides)
    - but if so, username should not be changeable

- users, tenants use this model

PUT could also be supported, but we won't add it to the core API right now. In fact, we're not going to add user modification to the core API either. We'll leave them as API extensions for now.

#update/overwrite user (consider if-match ETAG or if-unmodified - but not core yet)
PUT /users/uid - not doing this for core, now
    {username: newuniqueid, other data...}
    200 OK - this is an update
    403 if username=uid in backend