RESTful relationships

Adam Young ayoung at redhat.com
Mon Mar 22 15:40:32 UTC 2010


What is a consumer?  If it is something "permanent" in our sytem, then 
we shouldn't be deleting it.

What are we trying to achieve here?  If it is the removal of the 
relationship between a computer system  and a candlepin server, then 
lets delete that relationship.  This is really the same approach/design 
decision the Database folks have been dealing with longer than I've been 
around.

What ever we do  will work well for some use cases and less well for 
others.  The better the visibility we have to how it is going to be 
used, the better we will chose to implement.


On 03/22/2010 11:26 AM, Devan Goodwin wrote:
> Are we sure the distinction between delete and terminate should be
> exposed over the API, or is it something we should handle internally /
> automatically when the call to delete came in? Could we use the delete
> metaphor normally, for all intents and purposes the consumer is gone
> as far as the API is concerned, and the event/state of that consumer
> and his entitlements is recorded via some separate mechanism.
> (information which may be available via some separate API calls) If
> this *is* auditing driven anyhow, and if so do we also need to think
> about auditing bind/unbind events in general?
>
> If it is something we want exposed in API, I think I like the PUT +
> status update best as well, less the terminate "method" in the URL get
> us mocked and humiliated when the REST community catches wind of it.
> :)
>
> Cheers,
>
> Devan
>
> On Mon, Mar 22, 2010 at 12:12 PM, Bryan Kearney<bkearney at redhat.com>  wrote:
>    
>> I think I favor PUT /cp/consumer/{id} with body containing status update
>> as long we allow someone to post up on the consumer_id and the status.
>> If the rule is that they should repost the entire document, then I would
>> be for
>>
>> PUT/POST /cp/consumer/{id}/terminate
>>
>> -- bk
>>
>> On 03/19/2010 02:53 PM, Jesus M. Rodriguez wrote:
>>      
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Looking into how to terminate a consumer, which to me means we want
>>> to unentitle it. There are a few ways of doing this (not all of them
>>> are good) :)
>>>
>>> Part of this stems from the fact that we want to keep DELETE pure
>>> and have it actually DELETE its resource, and not be overloaded to
>>> mean something else.
>>>
>>> Here are a few options (again some better than others):
>>>
>>> * PUT /cp/consumer/{id} with body containing status update
>>>
>>>     So we could use the above to both update the consumer data as well as
>>>     change its state to terminated (or whatever we call it). This would
>>>     result in a more complex resource method having to check if there's
>>>     a status change, etc.
>>>
>>> * PUT/POST /cp/consumer/{id}/terminate
>>>
>>>     essentially call the terminate method on a consumer, this is VERY
>>>     non-RESTy and would make a RESTafarian cry
>>>
>>> * DELETE /cp/consumer/{id}
>>>
>>>     this really shouldn't be the sole way of terminating a consumer, this
>>>     really is meant for removing a consumer.
>>>
>>> So Adrian suggested maybe having an active and inactive collection, and
>>> that got me looking up relationships between resources. It seems the
>>> RESTful way is to model the relationship as a resource itself.
>>>
>>> For example, if Alice and Bob get married, you wouldn't want to update
>>> /alice/ and /bob/. You want to PUT a request to /marriage, etc. with
>>> alice and bob as the payload. That resource would make the appropriate
>>> relationship changes.
>>>
>>> Using that as an example, we could then go with something along the
>>> lines of:
>>>
>>>      DELETE /entitle/{consumerid}
>>>
>>> to remove the relationship
>>>
>>>      POST /entitle/{consumerid}
>>>
>>> to create the relationship.
>>>
>>> I'm not entirely sure how this would fit with the current discussions
>>> around bind/unbind as they seem very related :)
>>>
>>> We have a mail out to some of the deltacloud guys to see if they
>>> have any opinions as well.
>>>
>>> Thoughts?
>>>
>>> jesus
>>>
>>> - --
>>> jesus m. rodriguez          | jesusr at redhat.com
>>> principal software engineer | irc: zeus
>>> red hat systems management  | 919.754.4413 (w)
>>> rhce # 805008586930012      | 919.623.0080 (c)
>>> +---------------------------------------------+
>>> |   "Those who cannot remember the past       |
>>> |    are condemned to repeat it."             |
>>> |                        -- George Santayana  |
>>> +---------------------------------------------+
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.9 (GNU/Linux)
>>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAkujyBMACgkQvJZ57YntiYNY4QCfVY4BnQSw8c/wZStTei7f9LhD
>>> 5MwAniGBx7vSfixqS7r2Qz3BBfedLx8N
>>> =RsW7
>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> candlepin mailing list
>>> candlepin at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/candlepin
>>>        
>> _______________________________________________
>> candlepin mailing list
>> candlepin at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/candlepin
>>
>>      
>
>
>    




More information about the candlepin mailing list