- From: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk>
- Date: Wed, 16 Feb 2011 07:29:44 +0000
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
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. +1 >> 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). Correct? Ben
Received on Wednesday, 16 February 2011 07:46:31 UTC