openstack team mailing list archive

[Bryan Taylor <btaylor@xxxxxxxxxxxxx>]

PUT --  I talked to Jorge about this use of PUT — he agrees with me, so chat him up on this. PUT means to store the representation state at the given URI. It's thematic that if you PUT a representation of a given media type and then do a GET of that type, you get back a representation that is equivalent to what you PUT. So if you do a GET at /users to see a collection, I'd expect PUT to send an updated full collection. You might do a PUT on /users/{username} to create or update the new resource.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6

ATOM — yeah, maybe that should be confined to an extension. Some LDAP implementations support persistent searches, but a general solution would require getting between the web service API and the back-end store. In many cases you might be best to access the back-end's persistence store or APIs directly or write a custom replication consumer/miner. BTW, a common use case supporting this is that tenant's and operator's compliance policies will require fast propagation of access revocation to other systems . This comes up over and over again at Rackspace and it's a serious barrier to adopting systems that are accessible outside the internal network and it has been a deal breaker for many such systems.


From: Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx<mailto:ziad.sawalha@xxxxxxxxxxxxx>>
Date: Tue, 21 Jun 2011 23:49:28 -0500
To: Bryan Taylor <btaylor@xxxxxxxxxxxxx<mailto:btaylor@xxxxxxxxxxxxx>>, "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal

On PUT operations:
The identifier for users right now (username) is supplied in the payload, so it is a PUT. Same with groups.

On ATOM:
I agree with the principle, but the challenge will be picking up changes on a back-end store (like LDAP) and publishing ATOMs on those.