Subject: 409 Conflict - exposing more details

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Feb 2011 17:02:39 +0100

Hi,

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?

Best regards, Julian

---

From: Jan Algermissen <[email-masked]>
Date: Mon, 14 Feb 2011 19:34:27 +0100

Julian.

On Feb 14, 2011, at 5:02 PM, Julian Reschke wrote:

> Hi,
> 
> 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?

Not sure. I think I would try to model the aggregate in a way that the parts (that cannot exist without the whole) have URIs that are below the aggregate's URI. That way, they are automatically 'removed'. Part-whole relations being synonymous for your 'strong reference'.

So it is maybe more a design problem than a technical one?

Jan

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Feb 2011 19:40:50 +0100

> So it is maybe more a design problem than a technical one?

For many relations this works and of course is preferable.

In the case I'm currently looking there's a mix of references I can 
expose as URI hierarchy (and I do), and some others that do not seem to fit.

I may be able to workaround this by defining multiple hierarchies (like 
in WebDAV bindings), but this seems to be a rather complex solution to 
what should be a simple problem...

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 14 Feb 2011 11:02:43 -0800

> 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, ...

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Feb 2011 20:20:24 +0100

> required-by, dependency-of, bound-to, ...

"dependency-of" sounds good to me.

Best regards, Julian

---

From: Wenbo Zhu <[email-masked]>
Date: Mon, 14 Feb 2011 18:32:23 -0800

On Mon, Feb 14, 2011 at 11:20 AM, Julian Reschke <[email-masked]>wrote:

>>> 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.
>>>
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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Feb 2011 08:51:54 +0100

On 15.02.2011 03:32, Wenbo Zhu wrote:
>
>
> On Mon, Feb 14, 2011 at 11:20 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> 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?
>
>
> "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

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Wed, 16 Feb 2011 07:29:44 +0000

On 14 Feb 2011, at 19:20, Julian Reschke wrote:

>> A link relation makes sense.

+1

>>  What would you call it?

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Feb 2011 09:43:03 +0100

> Resource B "depends-on" resource A (where "depends-on" is implicit by the fact that resource B references resource A).

Yes. As long as we don't forget that not any reference is a strong 
reference.

Best regards, Julian