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: Tue, 15 Feb 2011 08:51:54 +0100
Message-ID: <4D5A309A.3070900@gmx.de>
To: Wenbo Zhu <wenboz@google.com>
CC: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 15.02.2011 03:32, Wenbo Zhu wrote:
>
>
> On Mon, Feb 14, 2011 at 11:20 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto: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?

Good question.

I also considered to just declare that *any* link returned in a 409 
Conflict is for a resource that prevented the deletion; but that feels 
like a hack.

>...

Best regards, Julian
Received on Tuesday, 15 February 2011 07:52:41 GMT

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