To PUT or to POST

Bug #843075 reported by klmitch
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
High
Unassigned

Bug Description

Question to the list that has some merit...

Jason

-----Original Message-----
From: <email address hidden>
[mailto:<email address hidden>] On
Behalf Of Mellquist, Peter
Sent: Wednesday, July 20, 2011 5:46 PM
To: <email address hidden>
Subject: [Openstack] [Keystone] usage of PUT and POST in APIs

Looking through the latest Keystone code and developer guide I have noticed
some differences in the usage of PUT and POST CRUD operations.

Resource Creation admin.py Developer Guide Says
................................................................
Tenant PUT or POST PUT in table 5.2.4 OR POST in
section 5.4.1 ?
Tenant Group PUT or POST NA
Users PUT or POST PUT in table 5.2.2
Global Group PUT or POST NA
Role Ref POST POST in table 5.2.6 and section
5.6.4
Endpoints POST POST in table 5.2.5 and section
5.5.4

Questions:
Is there any reason why Tenants and Users allow PUT and POST for creation
while Roles and Endpoints only allow POST?

Would it be possible to go only with POSTs in the above areas?

The developer guide does not match the current code in the above areas,
these may just be typos at this stage but it would be good to clarify what
the real APIs should be.

Peter.

Revision history for this message
klmitch (q-noreply) wrote :

Looks like we got to stick to POSTs as a part of effort to standardize operations across openstack.

Revision history for this message
klmitch (q-noreply) wrote :

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

Revision history for this message
klmitch (q-noreply) wrote :

See https://blueprints.launchpad.net/keystone/+spec/identity-api for latest API. Settling on POST for two reasons:

  1. auto-generated user/tenant ID (means you cannot PUT since you don't know the ID)
  2. POST allows partial updates (select one field to update instead of the whole object)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.