<div dir="ltr">Thanks for a very complete answer.<div><br></div><div><div>While I agree that it's OK if there is only going to be one secret to use the Accept type (it is actually a nice idea), it doesn't seem that MIME types are really suitable if there are multiple secrets per URI.</div>
<div><br></div><div>So I don't think that fixing this should be punted too far into the future, given that it sounds like you'll have to break the API (and thus all tests, docs, clients, compatible implementations etc).</div>
<div><br></div></div><div class="gmail_extra"><div>Justin<br><br></div>
<br><br><div class="gmail_quote">On Sun, Sep 22, 2013 at 10:13 PM, John Wood <span dir="ltr"><<a href="mailto:john.wood@rackspace.com" target="_blank">john.wood@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="direction:ltr;font-size:10pt;font-family:Tahoma">Hello Justin,
<div><br>
</div>
<div>First off, the current implementation of Barbican <span style="font-size:10pt">only supports one encrypted payload per secret record. We plan to revisit this once we begin work on the SSL certificate processing features. </span></div>
<div><br>
</div>
<div>As for the Barbican API, please note that the latest Barbican API is located here: <a href="https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface" target="_blank">https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface</a></div>
<div><br>
</div>
<div>As detailed in this wiki page, t<span style="font-size:10pt">he current implementation of Barbican utilizes an 'Accept' request header to indicate to the Barbican service which media type to return the secret in. If 'application/json' is provided, only
the secret's metadata is returned (i.e. nothing is decrypted). Alternate 'Accept' types may then be used to decrypted and return the secret, such as 'application/octet-stream' from binary secret types, and 'text/plain' for text based secrets. </span></div>
<div><br>
</div>
<div>Effectively these are different representations of the same REST-ful secret resource, which we believe is an acceptable <span style="font-size:10pt">(no pun intended) </span><span style="font-size:10pt">use of the 'Accept' header, but open for further
debate. </span></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><span style="font-size:10pt">That said, we did encounter an issue related to the 'Accept-Encoding' request header. We had hoped to use this header to indicate if (for example) a binary secret should be returned as 'base64' encoded versus raw binary data.
We found the ability to override this header from default was problematic on Chrome, so decided to hold off on this feature for now. Curiously one option discussed was to add a '/base64' extension to the URI. Hence this feature could similarly be open for
debate. </span></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><span style="font-size:10pt">BTW, we do have a Python client library available for interaction with Barbican as well: </span><a href="https://github.com/cloudkeep/python-barbicanclient" style="font-size:10pt" target="_blank">https://github.com/cloudkeep/python-barbicanclient</a></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><span style="font-size:10pt">Thanks,</span></div>
<div><span style="font-size:10pt">John</span></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><span style="font-size:10pt"><br>
</span></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div style="font-size:16px;font-family:Times New Roman">
<hr>
<div style="direction:ltr"><font face="Tahoma" color="#000000"><b>From:</b> Justin Santa Barbara [<a href="mailto:justin@fathomdb.com" target="_blank">justin@fathomdb.com</a>]<br>
<b>Sent:</b> Sunday, September 22, 2013 2:25 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> [openstack-dev] [Barbican] MIME types vs path (secrets/{id}/{name})<br>
</font><br>
</div><div class="im">
<div></div>
<div>
<div dir="ltr">
<div>As part of my project to add a second implementation of the OpenStack API, I'm implementing Barbican, and I'm struggling to understand the motivations behind the API spec.</div>
<div><br>
</div>
The API supports storing multiple secrets under a given key, the canonical example for that being SSL keys which comprise a certificate/public key and a private key. That makes sense.
<div><br>
</div>
<div>
<div>But, to set or retrieve the "sub-secrets", the MIME type of the request is used. 'application/json' is special and retrieves the metadata.</div>
<div><br>
</div>
<div>Wouldn't it be much easier just to use a path ( i.e. .../secrets/{id}/{name} ), rather than using MIME types? Using MIME types seems very un-RESTy, but I'll leave that argument to the REST police :-)</div>
<div><br>
</div>
<div>It seems much more complicated to use MIME types, so I'm betting there's a good reason. Can someone from the Barbican team share what those are?<br>
<div><br>
</div>
<div>(The API ref I'm looking at is here: <a href="https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp" target="_blank">https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp</a> )</div>
<div><br>
</div>
<div>
<div>Justin<br>
<br>
---<br>
<br>
Justin Santa Barbara<br>
Founder, FathomDB<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div>
</div>
</div>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>