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.w...@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 [jus...@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
