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 GMT

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