Re: 409 Conflict - exposing more details

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