Open Stack

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 at rackspace.com<mailto:ziad.sawalha at rackspace.com>>
Date: Tue, 21 Jun 2011 23:49:28 -0500
To: Bryan Taylor <btaylor at rackspace.com<mailto:btaylor at rackspace.com>>, "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110625/31deacb2/attachment.html>