- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 15 Feb 2011 08:51:54 +0100
- 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 UTC