<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div><br>
</div>
<div>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.</div>
<div><a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6">http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6</a></div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Ziad Sawalha <<a href="mailto:ziad.sawalha@rackspace.com">ziad.sawalha@rackspace.com</a>><br>
<span style="font-weight:bold">Date: </span>Tue, 21 Jun 2011 23:49:28 -0500<br>
<span style="font-weight:bold">To: </span>Bryan Taylor <<a href="mailto:btaylor@rackspace.com">btaylor@rackspace.com</a>>, "<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>" <<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openstack] OpenStack Identity: Keystone API Proposal<br>
</div>
<div><br>
</div>
<div>On PUT operations:</div>
<div>The identifier for users right now (username) is supplied in the payload, so it is a PUT. Same with groups.</div>
<div><br>
</div>
<div>On ATOM:</div>
<div>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.</div>
<br class="Apple-interchange-newline">
</span>
</body>
</html>