Open Stack

Thanks for a very complete answer.

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.

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).

Justin



On Sun, Sep 22, 2013 at 10:13 PM, John Wood <john.wood at rackspace.com> wrote:

>  Hello Justin,
>
>  First off, the current implementation of Barbican only supports one
> encrypted payload per secret record. We plan to revisit this once we begin
> work on the SSL certificate processing features.
>
>  As for the Barbican API, please note that the latest Barbican API is
> located here:
> https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface
>
>  As detailed in this wiki page, the 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.
>
>  Effectively these are different representations of the same REST-ful
> secret resource, which we believe is an acceptable (no pun intended) use
> of the 'Accept' header, but open for further debate.
>
>  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.
>
>  BTW, we do have a Python client library available for interaction with
> Barbican as well: https://github.com/cloudkeep/python-barbicanclient
>
>  Thanks,
> John
>
>
>
>
>
>
>
>  ------------------------------
> *From:* Justin Santa Barbara [justin at fathomdb.com]
> *Sent:* Sunday, September 22, 2013 2:25 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Barbican] MIME types vs path
> (secrets/{id}/{name})
>
>   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.
>
>  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.
>
>  But, to set or retrieve the "sub-secrets", the MIME type of the request
> is used.  'application/json' is special and retrieves the metadata.
>
>  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 :-)
>
>  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?
>
>  (The API ref I'm looking at is here:
> https://github.com/cloudkeep/barbican/wiki/Blueprint%3A-MIME-Type-Revamp )
>
>  Justin
>
> ---
>
> Justin Santa Barbara
> Founder, FathomDB
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130922/710d786b/attachment.html>