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: > >>>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. > >
OK, 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, [email protected] Software Engineer, CloudForms
