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.