W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2011

Re: 409 Conflict - exposing more details

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 16 Feb 2011 09:43:03 +0100
Message-ID: <4D5B8E17.9040105@gmx.de>
To: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
CC: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 16.02.2011 08:29, Benjamin Niven-Jenkins wrote:
>
> On 14 Feb 2011, at 19:20, Julian Reschke wrote:
>
>> On 14.02.2011 20:02, Roy T. Fielding wrote:
>>> On Feb 14, 2011, at 8:02 AM, Julian Reschke wrote:
>>>
>>>> in a project I'm currently working on, my server returns 409 Conflict when trying to DELETE a resource that still has strong references from other resources -- so what I want to tell the client is that you can't DELETE resource A as long as resource B references it.
>>>>
>>>> Now, with close coupling between client and server this can easily be communicated in the response body, be it JSON or XML.
>>>>
>>>> However, I was wondering whether this use case is common enough to standardize it? Maybe with a link relation?
>>>
>>> A link relation makes sense.
>
> +1
>
>>>   What would you call it?
>>> required-by, dependency-of, bound-to, ...
>>
>> "dependency-of" sounds good to me.
>
> Just so I have the model clear in my head...
>
> If one has a resource A that cannot be DELETEd as long as resource B references it, then:
>
> Resource A is a "dependency-of" resource B.
> Resource B "depends-on" resource A (where "depends-on" is implicit by the fact that resource B references resource A).
>
> Correct?
> ...

Yes. As long as we don't forget that not any reference is a strong 
reference.

Best regards, Julian
Received on Wednesday, 16 February 2011 08:43:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT