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

Re: 409 Conflict - exposing more details

From: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Wed, 16 Feb 2011 07:29:44 +0000
Message-Id: <4E77D3C3-0095-44C6-B5FF-DA51CEB63CE4@niven-jenkins.co.uk>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

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.


>>  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).


Received on Wednesday, 16 February 2011 07:46:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:56 UTC