Re: RFC: API changes

[Bryan Kearney]

On 03/03/2010 03:32 PM, Adrian Likins wrote:
> On 03/03/2010 03:13 PM, Devan Goodwin wrote:
> > On Wed, Mar 3, 2010 at 2:25 PM, Bryan Kearney   wrote:
> > > PUTTING IT ALL TOGETHER
> > >
> > > I think the following APIS which are docuemnted at:
> > >
> > > https://fedorahosted.org/candlepin/wiki/API
> > >
> > > would change
> > >
> > > registerConsumer (aka POST /consumer):
> > >          POST /consumers
> > >
> > > unregisterConsumer (aka DELETE /consumer/{cosumer_uuid}):
> > >          DELETE /consumers/{consumer_uuid}
> > >
> > > syncCertificates (aka POST /consumer/{consumer_uuid}/certificates):
> > >          POST /consumers/{consumer_uuid}/certificates
> > >          This is a bit off standard, but I think we are ok
> >
> > NOTE: this transfer the responsibility for determine what gets thrown
> > out and what doesn't from the server to the client tools. I think this
> > is a good thing, rather than the client saying "here's what's on the
> > box, you figure out what I need, and send me instructions on what to
> > do with each which I'll act on", the client would now say "what should
> > I have and I'll act on that" and then acts on those results. To me
> > this seems more logical.
>   I'm not a big fan of the sync call at all. I'd rather it just
>
> return all the currently valid certs.  Not sure thats workable
> though.
>   Just returning all certs presents some problems from a ui
>
> standpoint, as
> it would be nice to be able to detect invalid certs before
> actually using them to make calls. And if entitlements are
> not x509's tied to content servers, then we can't invalidate
> them that way, and sync is probably the only way to figure
> out they are invalid.

How about we agree on all the stuff except this call? We could come back 
and and figure this one out.
> > > bind:
> > >          POST /entitlement/consumer/{consumer_uuid}/product/{product_id}
> > >          becomes
> > >          POST /consumers/{consumer_uuid}/entitlements?product={product_id}
> > >      POST /entitlement/consumer/{consumer_uuid}/token/{registration_token}
> > >      becomes
> > >      POST /consumers/{consumer_uuid}/entitlements?token={registration_token}
> > >
> > >      POST /entitlement/consumer/{consumer_uuid}/pool/{pool_id}
> > >      becomes
> > >      POST /consumers/{consumer_uuid}/entitlements?pool={pool_id}
> >
> > Only part of this I'm wondering about, should those be query params or
> > form params? I can't find any examples of using query params when
> > doing a POST, I think that's usually passed in via the message body.
> > Thoughts?
>   Query params on the url seem okay to me. Not sure what
>
> the body would need to look like do it on the body (and/or, what
> can jersey do to handle that?)
>   That said, the /entitlement/consumer/{consumer_uuid}/pool/{pool_id}
>
> style is fine with me as well.
> > >      All of these should return a new entitlement
> >
> > Agreed!
>   slightly redundant with the sync call, but I think it makes
>
> more sense to return entitlements here as well. Prad at least
> wants this.

I like the idea of ../RESOURCE returning a RESOURCE

-- bk