On Tue, Oct 16, 2012 at 11:24:43PM -0700, Richard Su wrote:
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:
>>>I am working on show action for Provider Type API and I am not sure if
>>>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.
>>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.
>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
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
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.
I will follow route for shallow resources when reading Provider Type -
so it means that I will implement Credential Definition as resource too.
This looks simple way even if it is more code.
Next I can parse params to make it work
with embedded Credential Definition in Provider Type XML.
Petr Blaho, pblaho(a)redhat.com
Software Engineer, CloudForms