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

Re: 409 Conflict - exposing more details

From: Wenbo Zhu <wenboz@google.com>
Date: Mon, 14 Feb 2011 18:32:23 -0800
Message-ID: <AANLkTimkV5xwZuxiX3TnxTvXX3_C1345qGQvk2c+b6kU@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Feb 14, 2011 at 11:20 AM, Julian Reschke <julian.reschke@gmx.de>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.
Do you want to separate the actual relation from its properties, e.g.
"restrict" in this case, similar to different foreign-key constraints in the
relational data model?

Either way, I'd be happy to see such a standardized link relation, as I
happen to be looking for a way to solve the following use case:

Imagine updates are ordered per each resource, for replication purposes, and
the presence of such a relation indicates cross-resource ordering is
required, because the associated DELETE and CREATION operations are not
commutative any more even though they target two different resources.

- Wenbo

> Best regards, Julian
Received on Tuesday, 15 February 2011 02:32:52 UTC

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