RFC: to show Credential Definitions with Provider Type or not

Jason Guiditta jguiditt at redhat.com
Tue Oct 16 20:20:46 UTC 2012


On 09/10/12 14:31 -0400, Scott Seago wrote:
>On 10/09/2012 12:31 PM, Petr Blaho wrote:
>>Hi,
>>
>>I am working on show action for Provider Type API and I am not sure if I
>>should include Credential Definitions in XML representation of Provider
>>Type resource at all (probably bad idea), use only ids and hrefs or if
>>hsould I include the whole subresource there.
>>
>>The similar question goes for create action. Should the user
>>be able to create new Credential Definitions from within Provider Type
>>data XML provided to create action? And the same for update action.
>>
>>Or should be Credential Definition resource of its own?
>>
>>Looking for your input.
>>
>>--
>>
>>With Regards
>>Petr Blaho
>
>I'm thinking that it really belongs to the provider type, so I'm not 
>sure we want it as a separate subresource. It's really just a modeling 
>convenience that the CredentialDefinition is a separate object, since 
>the number is variable, etc. Part of the  definition of a provider 
>type is the list of attributes for provider account credentials.
>
>Scott
>

I am on the fence here.  I agree that a Credential Definition is meant
to be used with a Provider Type.  But is it true that the Credential Def
would never have a need to be used by itself?  That I am less sure of.
I think allowing a credential definition to be created when creating a
provider type is absolutely valid (ie, nested objects POSTed to 
provider_type).  However, perhaps a user wants to see how many
credential definitions there are, or just look at (and perhaps update)
some of them.  Say I retrieve a list from
provider_types/1/credential_definitions.  This list shows me I have 2
different defs for one of my provider types.  I then want to go and
look at them directly, and then perhaps delete the duplicate (I know,
we have model validations to prevent this, it is just an example).
The point is, I actually want to go to credential_definitions/1, and
then PUT an update to same, rather than having that extra layer of
going through the provider_type.

I'll note the additional question of 'how do I figure out what kinds
of credentials a given provider type needs' remains a bit ambiguous in
my mind, but I think that is a separate problem.

Lastly, to answer the other part of the question, I think we have been
shooting for generally following the 'shallow resource' approach,
which would mean you include only the link to the proper uri so the
client can go and get the given credential defs they need.  That said,
we have some places where we allow the client to specify the want the
full resource, which I personally think is kind of a nice option to
provide (with a shallow default) in places like this, where the client
is likely to have to make a bunch of subsequent requests to look at
the details.

-j



More information about the aeolus-devel mailing list