RFC: to show Credential Definitions with Provider Type or not

Richard Su rwsu at redhat.com
Wed Oct 17 06:24:43 UTC 2012


On 10/16/2012 01:20 PM, Jason Guiditta wrote:
> 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

Having credential_definitions implemented as a full resource would
add some flexibility to updates.

Which would be easiest to implement? (1) Having the credential
definitions defined as part of the provider type definition? And not expose
  them as a separate resource at all. or (2) Implement the definitions
as a full resource.

I can see a case for having both. Personally I would go with the easier 
option
for now. We have other endpoints to implement that are of higher strategic
priority. Once we have those done, we can circle back and implement the
option we skipped.





More information about the aeolus-devel mailing list