RESTful relationships

Devan Goodwin dgoodwin at rm-rf.ca
Mon Mar 22 15:26:51 UTC 2010


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
>



-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca



More information about the candlepin mailing list